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RESUMO 


Este trabalho de conclusão de curso objetiva o estudo detalhado e o desenvolvimento de 
interfaces gráficas para sistemas embarcados, através da utilização de instruções de programação 
e comandos para hardware e software, usando o sistema operacional Linux. 

No trabalho, são apresentados de forma detalhada os elementos conceituais dos circuitos 
eletrônicos digitais e suas características, dando relevância às suas particularidades de arquitetura 
e comunicação. Também são explicados programas para sistemas embarcados empregando micro- 
controladores AVR, além de interfaces com o framework wx Widgets e a biblioteca gráfica GTK+ 
no Linux. 

Experimentalmente, utilizando um microcontrolador AVR gerenciado por conexão USB- 
USART, foram realizados e apresentados exemplos explicativos de interface gráfica de usuário em 
ambiente Linux PC. Ainda, é demonstrado um sistema combinado de uma interface gráfica que 
interage com um sistema embarcado, além de uma aplicação particular na qual tais comportamen- 
tos são tornados independentes e paralelos do ponto de vista do usuário. 

Os resultados alcançados demonstram que as interfaces gráficas para sistemas eletrônicos 
em ambiente operacional Linux são uma possibilidade prática e que seu desenvolvimento pode ser 
facilitado por um material descritivo e simples. Estas características que podem facilitar e incenti- 


var a construção de ferramentas para interação homem-máquina em software aberto. 


PALAVRAS-CHAVE: Interação homem-máquina. Interface gráfica. Microcontroladores AVR. 


Ambiente operacional Linux. 


ABSTRACT 


This work aims to the detailed study and the development of graphical interfaces for em- 
bedded systems, that done through the utilization of programming instructions and commands for 
hardware and software using the Linux operating system. 

During the development the conceptual elements of digital electronic circuits and their char- 
acterístics are presented, giving relevance to the particularities of architecture and communication. 
It is also explained about programs to embedded systems making use of AVR microcontrollers, 
besides interfaces written with the wx Widgets framework and the graphical library GTK+ in Linux. 

Experimentally, based on AVR microcontroller managed by USB-USART connection, it 
were created and featured a set of explanatory examples of graphical user interface within the Linux 
PC environment. Also, it is demonstrated a combined system of a graphical interface which inter- 
acts with an embedded system, besides the presentation of a particular application in which those 
behaviors are made independent and parallel with respect to the user. 

The achieved results show that the graphical interfaces for electronic systems in Linux op- 
erational environment are a practical possibility and that their development is facilitated by a de- 
scriptive and simple material. Such characteristics may stimulate the construction of tools, focusing 


in human-machine interaction, with free software. 


KEYWORDS: Human-machine interaction. Graphical interface. AVR microcontrollers. Linux 


operational environment. 
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INTRODUÇÃO 


1 INTRODUÇÃO 


A década de 1980 do último século foi o período de grande expansão das tecnologias digi- 
tais ligadas ao mundo da informática. No início da chamada era da informática, os computadores 
funcionavam baseados em uma interface de linha de comando, onde o usuário digitava e enviava 
instruções para o processamento dos computadores, que retornava com as informações em forma 
de resultados para interpretação e decisão do usuário. Eram uma interação homem-máquina à base 
de comandos simples, diretos, precisos e digitados, que eram endereçados ao processador em lin- 


guagem específica, utilizando-se o idioma inglês. 


Com o desenvolvimento do sistema operacional denominado MS-DOS (Microsoft Disk 
Operating System, do inglês) para microcomputadores PC (Personal Computer, do inglês), sof- 
tware da empresa Microsoft, ocorreu uma verdadeira revolução na forma de interação do compu- 
tador PC: a presença do hardware, através dos programas instalados, e dos softwares, tornando 
relativamente amigável a utilização dos microcomputadores como instrumento de auxílios às di- 
versas tarefas presentes nas atividades humanas. A utilização de linhas de comando tornara-se, com 
o MS-DOS, a única forma do usuário interagir com o computador e ainda hoje se utiliza esse mé- 
todo de interação, através de terminal de comandos, para a execução de tarefas específicas nos 


computadores. 


Com o avanço da tecnologia digital a Microsoft e a Apple desenvolveram sistemas operaci- 
onais com interfaces gráficas que, aliadas ao uso de dispositivos apontadores como o mouse, eli- 
minou as barreiras e a necessidade de usar comandos e preparou o mundo da informática para o 
domínio dos ícones, janelas, botões etc. O computador tornava-se mais amigável e ferramenta in- 
dispensável à realização de tarefas humanas cada vez mais complexas e frequentes; então os ter- 
minais de comandos dos sistemas operacionais deixaram a linha de frente da interação homem- 
máquina, passando a ser utilizados apenas nas tarefas complexas, desenvolvidas por usuários avan- 
çados dos computadores. Estes são uma ferramenta muito forte e utilizada nos sistemas operacio- 
nais Unix e Linux — Windows por algumas versões — numa filosofia de coexistência com a interface 


gráfica, dominante nos computadores atuais. 
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Este trabalho tem como proposta o estudo e desenvolvimento de interfaces gráficas em PC 
para uso em sistemas embarcados. Nesse particular, é importante destacar que a utilização da linha 
de comandos em modo texto ainda oferece algumas praticidades comparado com a interface grá- 
fica, pois agilizam tarefas que de outro modo demandariam mais tempo de atividade pela necessi- 
dade de serem acessadas por janelas, menus ou submenus etc. Exemplo clássico disso são os co- 
mandos do Linux, que não precisam ser necessariamente usados, pois as interfaces gráficas mais 
modernas acompanham diversas ferramentas de configuração sofisticadas. Entretanto, estas nem 


sempre são simples e objetivas, requerendo diversos cliques para serem realizadas. 


Os sistemas embarcados vêm, cada vez mais, revolucionado o mundo, pois estão em prati- 
camente todos os lugares e suas aplicações impulsionaram o desenvolvimento tecnológico de todas 
as áreas do conhecimento da atividade humana: salvam vidas marca-passos, garantem a segurança 
dos transportes em computadores, possibilitam a facilidade das comunicações através dos satélites, 


são aplicados aos sistema de redes elétricas, em sistemas bélicos, em reatores etc. 


O presente trabalho de conclusão de curso objetiva o estudo detalhado e o desenvolvimento 
de interfaces gráficas para sistemas embarcados, através da utilização de instruções de programa- 
ção e comandos para hardware e software, usando o sistema operacional Linux. No trabalho, será 
apresentado um diagnóstico teórico para esclarecer a complexidade da interface gráfica que se co- 
munica com um sistema eletrônico, explicando-o de forma detalhada e passo-a-passo. Também 
será apresentado o desenvolvimento de um projeto simplificado de interface de aplicação em com- 
putadores, utilizando componentes virtuais, com a finalidade da interação com equipamentos elé- 
tricos e eletrônicos de uso geral. 

A fundamentação teórica contemplou elementos de hardware e detalhes de software relati- 
vos à temática do trabalho, com aqueles tratando sobre concepções de circuitos digitais e micro- 
processadores — modelos específicos, meios de comunicação — e estes abordando as aplicações 
computacionais e códigos interessantes para os objetivos a serem alcançados. Tais procedimentos 
demonstram a relevância do dimensionamento racional do hardware e do software. Finalmente, o 
desenvolvimento e exemplificações finais do trabalho aplicaram as linguagens C e C++, no Ubuntu 
Linux 14.04, para materializar interfaces gráficas com GTK+ wx Widgets capazes de comunicação 


com sistemas com a família AVR de microcontroladores. 
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Com o trabalho finalizado, deverá ser esclarecido o desenvolvimento de interfaces gráficas 
em PC para sistemas embarcados em AVR, uma tarefa abstrata e complexa. Isso incluindo a ne- 
cessidade de suas características serem previstas pelo projetista considerando a disponibilidade das 
ferramentas tecnológicas, seu alcance e seu domínio. Com isso, pretende-se incentivar a utilização 


de softwares livres para a interface homem-máquina. 


1.1 PROBLEMA E QUESTÃO DE PESQUISA 


O desenvolvimento das tecnologias eletrônicas digitais compreendem o estudo, projetos, 
técnicas e métodos de construção, utilizando placas de hardware com circuitos integrados e algo- 
ritmos de software, implementados para a automatização de tarefas nas mais diversas atividades 
humanas. 

A ampliação, expansão e aplicação das tecnologias digitais no mundo atual dependem cada 
vez mais da facilitação do uso dos equipamentos elétricos e eletrônicos empregados na execução 
de tarefas, processos e sistemas variados. A construção de meios de interface de comunicação, 
instrução, processamento e coleta de informações, para a eficácia da aplicação precisa e segura das 
tecnologias eletrônicas, dependem decisivamente da capacidade humana de criar mecanismos de 
interação homem-máquina, seja através de sistemas autônomos ou sistemas próprios de controle 
que venham a garantir a plena inserção e aplicação dos recursos tecnológicos na vida cotidiana e 
futura da humanidade. 

Nessa linha, ampliar a pesquisa e o conhecimento, no desenvolvimento de capacidades para 
a elaboração de ferramentas de interação entre sistemas de hardware e software, ganha importância 
no processo de assegurar o pleno desenvolvimento social e econômico das sociedades atuais. 

Assim sendo, surgem as interrogantes: o desenvolvimento de interfaces gráficas via softwa- 
res abertos, por meio da aplicação de sistemas computacionais, facilita a interação homem-máquina 
com sistemas eletrônicos embarcados? Será possível elaborar uma metodologia para o desenvolvi- 


mento de interfaces gráficas de sistemas embarcados na plataforma Linux? 
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1.2 OBJETIVOS 


Os objetivos deste trabalho estão decompostos em geral e específicos. 


1.2.1 OBJETIVO GERAL 


O objetivo geral deste trabalho acadêmico é contribuir para o estudo e o desenvolvimento 
das tecnologias de informação, no caso aplicadas aos processos de utilização de sistemas elétricos 
e eletrônicos baseados em microprocessadores. Assim, pretende-se viabilizar a utilização particular 
de instruções e códigos de sistemas de programação de computadores, para a construção de inter- 
faces gráficas voltadas para sistemas embarcados de propósitos variados, tendo como base o sis- 


tema operacional Linux de uso e acesso livre (open source). 


1.2.2 OBJETIVOS ESPECÍFICOS 


Como objetivos específicos, tem-se: 


1. Descrever os elementos essenciais de hardware e software, necessários à realização do 
processo de conexão e comunicação de dispositivos de aplicação; 

2. Explicar os conceitos básicos e fundamentais sobre sistemas microprocessados, arqui- 
teturas de barramentos e formatos específicos relacionados, abordando a variabilidade 
teórica de tais concepções; 

3. Apresentar as características dos sistemas operacionais baseados no núcleo Linux, in- 
cluindo detalhes históricos e de execução, enfatizando as interfaces de usuário; 

4. Mostrar o gerenciamento da comunicação USB, por programação, mediante exemplos 


explicativos em código para sistemas embarcados com microcontroladores AVR; 
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5. Emular sistemas constituídos de uma interface gráfica em Linux PC e de um sistema 
embarcado com a família AVR, sendo a relação entre as partes do tipo interdependente 
via USB. Para isto, foram utilizados os softwares auxiliares GTK+ e wxWidgets; 

6. Exemplificar casos de interface gráfica completa, ou seja, com escritas e leituras, que 
representem projetos eletrônicos reais, discutindo possibilidades de concorrência e ope- 


ração em tempo real. 


1.3 HIPÓTESES 


As hipóteses nas quais se baseia este trabalho são as seguintes: 


1. Utilizando o sistema operacional Linux, é possível administrar recursos tecnológicos 
tais como: barramentos de comunicação, famílias de microcontroladores etc.; estes re- 
lativos à estrutura do sistema embarcado. 

2. As interfaces possibilitam a segurança de manipulação de dados no processo de comu- 
nicação entre o sistema embarcado e o computador pessoal; isso devido à restrição do 
usuário às particularidades do hardware USB do PC por parte interface gráfica. 

3. Utilizando bibliotecas de interfaceamento gráfico em Linux, em acesso livre, como 
GTK+e wx Widgets, é possível implementar de maneira simples e eficaz a comunicação 
de um sistema embarcado com o usuário. 

4. A partir de procedimentos descritivos organizados passo a passo, pode-se suprir a falta 
de informação detalhada encontrada na literatura para o desenvolvimento de interfaces 
gráficas em ambiente Linux na comunicação com sistemas embarcados. 

5. Interfaces gráficas em Linux GTK+ são uma opção viável de ferramentas para a imple- 
mentação de comunicação de sistemas embarcados em geral; isso inclusive ao se tra- 


balhar com paralelismo e operações em tempo real. 
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1.4 MOTIVAÇÃO 


O conjunto de estudos e aplicações contemplado neste trabalho originou-se da experiência 
anterior do autor com diversas temáticas associadas à engenharia, incluindo a compreensão e busca 
do domínio dos fenômenos da energia e dos circuitos elétricos aplicados à dinâmica do mundo real. 

Outro aspecto motivador fundamental para a realização do trabalho acadêmico foi a asso- 
ciação do domínio de recursos computacionais adquiridos por autoestudo — estudo de linguagens 
C e C++, do sistemas operacionais Windows, Linux e outros — que serviram de suporte à aplicação 
dos projetos de estudo acadêmico realizados durante o desenvolvimento do curso de graduação, 
particularmente em casos associados à teoria das disciplinas “Microprocessadores I e II” da grade 
curricular do curso de Engenharia Elétrica. 

Especificamente, a idealização deste trabalho surgiu na elaboração de um projeto no qual 
foi desenvolvida uma interface gráfica e verificada a necessidade da construção da ferramenta para 
comunicação a partir de um computador externo com uma aplicação eletrônica embarcada, tanto 
do ponto de vista de sensoriamentos quanto de acionamentos. 

É possível destacar, também como elemento motivador, a prática do autor com as atividades 
de jogos eletrônicos computacionais, oportunidade para a abstração de conceitos e técnicas de pro- 
gramação por controle de processos, eventos, imagens etc. Até mesmo, nesse contexto, técnicas de 


inteligência artificial contidas nos softwares de jogos de videogame. 


1.5 JUSTIFICATIVA 


Em pesquisas realizadas, observou-se a limitação de bibliografia que mostre com detalhe o 
processo de criação de uma interface gráfica digital. Foram encontradas ferramentas pré-configu- 
radas para comunicação externa por portas de PC com objetivo de interação com diversas platafor- 
mas, na sua maioria drivers trabalhando com ambiente Windows. Tais meios que poderiam ser 
limitantes devido às suas características de velocidades de transmissão, tamanhos de pacotes de 
dados, bloqueios de escritas e leituras, entre outros. Como uma alternativa livre para tratar essas 


condições, pensou-se na possibilidade da construção das interfaces gráficas em ambiente Linux. 
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Com a elaboração deste trabalho pretende-se oferecer material bibliográfico didático, deta- 
lhado e aprofundado sobre o desenvolvimento de interfaces gráficas para sistemas embarcados. 
Isso torna-se necessário posto que há pouca literatura e deficiente informação organizada a esse 
respeito. 

O trabalho presta-se a ser um instrumento de conhecimento e análise da estrutura necessária 
para a elaboração e o desenvolvimento de sistemas tecnológicos, voltados para a construção de 
interfaces gráficas de usuário utilizadas na comunicação de equipamentos de propósito gerais e 
específicos, em atividades simples e complexas. 

De um modo específico, este trabalho acadêmico justifica-se pela proposta de oferecer a 
base para a fundamentação teórica e desenvolvimento de interfaces gráficas computacionais, utili- 
zando softwares abertos como alternativa às restrições dos softwares fechados. 

Ainda através deste estudo, é possível conhecer e enfrentar as principais dificuldades no 
desenvolvimento de aplicações computacionais, utilizando-se das ferramentas produtivas e essen- 
ciais a projetos, usando linguagens C/++ para acesso a funcionalidade do sistema operacional e 


suas funções e partes eletrônicas controláveis. 


1.6 ANTECEDENTES 


Foi realizado um projeto anterior desenvolvido como requisito de disciplina que deu origem 
a um artigo publicado em congresso por Santos et al. (2015) o qual se encontra no anexo do traba- 
lho. Projeto onde foi desenvolvida uma interface gráfica e verificada a necessidade da construção 
da ferramenta para comunicação a partir de um computador externo com uma aplicação eletrônica 
embarcada, tanto do ponto de vista de sensoriamentos quanto de acionamentos. Na ocasião, com a 
linguagem C++, a interface foi programada com o auxílio do IDE shareware e de código fechado 
C++ Builder da empresa Embarcadero, antiga Borland. Para o gerenciamento USB, era aplicado 


o software Termite da empresa CompuPhase para portas COM de PC. 


Na busca por informação, encontrou-se o artigo de Juliato (2014), em que é apresentada de 
maneira detalhada a manipulação de registradores, em firmware, para a comunicação USB com 
um sistema embarcado. No entanto, como em outros materiais, é verificada, além da aplicação do 


ambiente Windows, a falta de detalhes no interfaceamento USB por parte do sistema operacional, 
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sendo o padrão USB o tipo de barramento mais utilizado para comunicação com sistemas embar- 
cados. Nesse artigo, foi aplicada a linguagem CH com o IDE Visual Studio, ambos da Microsoft. 
Uma classe disponibilizada para o CH foi responsável, junto de um driver personalizado, pelo es- 


tabelecimento USB com um sistema embarcado com microcontrolador PIC, da empresa Microchip. 


Heydrick (2013) apresentou uma possibilidade atrativa de implementação de interface em 
linha de comando no ambiente Linux. No conteúdo também foi demonstrada, de forma detalhada, 
uma aplicação na plataforma embarcada Arduino por meio de tais algoritmos, o que incentivou a 
escolha do Linux como sistema operacional para o desenvolvimento da interface gráfica apresen- 
tada neste trabalho. Esse material instruiu a feitura de aplicativos na linguagem C, possibilitando 
associações com a linguagem C++, que é de ampla aplicação acadêmica e científica, além de ser 


tradicionalmente usada em interfaces gráficas de usuário. 


A inspiração para a estrutura de tutorial apresentada neste trabalho surgiu após a percepção 
da relevância das interfaces gráficas no acesso e compreensão de sistemas embarcados em geral, 
validada por Burhan e Othman (2016) em se tratando de comunicação facilitada com usuários lei- 
gos. Esse artigo científico trabalhou com a linguagem de programação Visual Basic para criação 
de interfaces gráficas e com microcontroladores PIC para sistemas embarcados. Apesar de sua 
utilidade, notou-se novamente a falta de códigos detalhados sobre a escrita do firmware PIC e sobre 


a programação da interface em Visual Basic. 


1.7 ESTRUTURA DO TRABALHO 


Para a elaboração do presente trabalho, foi necessário estruturá-lo em cinco capítulos ana- 
líticos de forma a possibilitar sua organização e melhor compreensão. 

O Capítulo 1 contempla os elementos essenciais à elaboração do estudo e trabalho de con- 
clusão do Curso de Bacharelado em Engenharia Elétrica, partindo das considerações introdutórias, 
onde é chamada atenção para a importância da expansão das tecnologias digitais e eletrônicas, no 
mundo do trabalho, do lazer, da ciência etc. Esse capítulo também apresenta objetivos, hipóteses, 


motivação, justificativa e antecedentes teórico-práticos que contribuíram para este trabalho. 
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O Capítulo 2 inicia considerando os elementos conceituais acerca dos circuitos eletrônicos 
digitais e suas características, contextualizando as principais invenções ocorridas nas áreas associ- 
adas, como a dos computadores microprocessados e sistemas embarcados, dando relevância aos 
detalhes de arquitetura e comunicação destes últimos. 

O Capítulo 3 faz um retrospecto da história e das distribuições do sistema Linux. Também 
são introduzidos os principais detalhes teóricos sobre os softwares de modo geral. Prossegue-se 
com abordagens sobre programas em sistemas embarcados empregando a tecnologia AVR, além 
de interfaces de usuário e bibliotecas gráficas no Linux. 

No Capítulo 4, apresenta-se a estruturação de um sistema experimental, por meio de exem- 
plos explicativos de interface gráfica de usuário em ambiente Linux PC, de modo que as funciona- 
lidades de um microcontrolador AVR fossem gerenciadas por conexão USB-USART. Isso com o 
auxílio de conhecimentos, principalmente, na área da programação de códigos e algoritmos com- 
putacionais. O capítulo finaliza com a apresentação de um sistema combinado de uma interface 
gráfica que interage com um sistema embarcado, tanto com sensoriamentos quanto atuações. Além 
disso, trata-se de uma aplicação particular na qual tais comportamentos são feitos independentes e 
paralelos, do ponto de vista do usuário. 

Finalmente, no Capítulo 5 são apresentadas conclusões, considerações, discussões, contri- 
buições e descobertas resultantes do estudo e desenvolvimento objetivados neste trabalho. Tam- 


bém, foram mencionados possíveis trabalhos que possam ser realizados futuramente. 
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2 MICROPROCESSADORES E TECNOLOGIAS APLICADAS 


Neste capítulo, serão apresentados noções sobre circuitos e lógica digital, definições para 
sistemas microprocessados, a arquitetura e padrões de barramentos, os processadores para sistemas 


embarcardos e, finalmente, os microcontroladores AVR. 


2.1 NOÇÕES SOBRE CIRCUITOS E LÓGICA DIGITAL 


Nesta seção, abordados o sistema de numeração binário, as formas de onda digitais, o pro- 


cessamento lógico por circuitos e os sistemas digitais de memória. 


2.1.1 SISTEMA DE NUMERAÇÃO BINÁRIO 


O sistema binário tem apenas duas imagens, que são o “0º eo “1”. Isso é uma grande van- 
tagem em um computador digital visto que, enquanto o ser humano tem dez dedos, um circuito 
elétrico chaveado tem somente dois estados — ligado e desligado — representando características 
elétricas como: alta ou baixa tensão; alta ou baixa corrente; e, baixa ou alta impedância. O raciocí- 


nio da numeração binária pode ser percebido pela Figura 2.1. 
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Figura 2.1 — A notação binária dos números decimais tradicionais. 


Binary Decimal 
0 0 
1 l 
10 z 
HM 3 
100 4 
101 5 
10 6 
11 7 
1000 8 
1001 9 
1010 10 
1011 1 
1100 12 
1101 13 
1110 14 
1111 15 
10000 16 


Fonte: Huggins (1981). 


No sistema decimal não há imagens maiores que “9”, então sempre que “1º é somado a “9º 
em qualquer ordem, o “9” é trocado por “0” e “1 é adicionado à maior ordem. Em binário, por sua 
vez, não há imagem maior que “1”, o que significa que tal modificação limitrofe deve ser efetuada 
mais frequentemente (HUGGINS, 1981). 

Para distingui-lo de um dígito decimal, um dígito binário é comumente chamado de BIT 
(Binary Digit, do inglês). Quando é necessário, o que é típico, para referir-se a um bit específico 
em um número usa-se uma representação minimizada: bit n indica o bit na n-ésima casa binária, 


isto é, que gera o numeral decimal correspondente a 2”. Isso é ilustrado na Figura 2.2. 
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Figura 2.2 — As casas binárias de um número decimal de 8 bits denotado no sistema binário. 


00101101 


bit? ——— | 
bit 6 
bit 5 
bit 4 
bit 3 
bit 2 
bit 1 


bit O 


Fonte: Huggins (1981). 


Considerações práticas de projeto ditam que os números binários movidos dentro de um 
computador devem todos ter o mesmo número de bits mesmo que sobrem espaços e seja necessário 
preencher com zeros redundantes. Esses números fixed-length — de comprimento fixo — como 
words ou palavras. A expressão word-length é aplicada para indicar o número de bits que pode ser 
manejado e mantido em cada local de armazenamento (HUGGINS, 1981). 

Os primeiros computadores digitais, particularmente aqueles focados em propósitos cientí- 
ficos, tinham word-length de até 40 bits, mas como armazenamento custava caro, os projetistas 
tinham que fazer uma compensação entre grandes palavras e o custo de guardar e manter as mes- 
mas. Os microprocessadores, dentro da moderna diversidade de sistemas computacionais, são pro- 


Jetados para ter word-lenghts de 4, 8, 16, 32 e 64 bits. 


2.1.2 FORMAS DE ONDA DIGITAL 


Uma vibração de um jeito específico, em um sistema físico — elétrico, hidráulico, térmico 
etc — pode ser considerada como uma função matemática no tempo f(t). Na presença de periodici- 
dade dessa função, passa-se a denominar o gráfico de f(t) de forma de onda. Isso, dentro dos siste- 


mas eletrônicos como um todo, produz o conceito de formas analógicas ou digitais, com estas 
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descritas como retangulares acima do eixo horizontal e com dois picos possíveis, enquanto aquelas 


são genéricas, abrangendo quaisquer gráficos periódicos. Representação na Figura 2.3. 


Figura 2.3 — Gráficos de funções digitais, à esquerda, e analógicas, à direita. 


Fonte: Editado de Floyd (2015). 


Os valores das formas de onda digitais são sempre binários, em outras palavras, “0” ou “1”. 
Possivelmente, são expressos em valores de tensão, corrente ou impedância, sendo mais frequente 
o uso da tensão elétrica. Outros nomes para os estados lógicos são níveis BAIXO e ALTO, ou 
desligado — inativo — e ligado — ativo — respectivamente para “0” e “1”. 

Verifica-se que, na prática, há momentos em que o nível de uma onda digital não é nem um 
dos estados, mas sim uma transição. Esse ponto idealmente é, inclusive, ambíguo na Matemática e 
conhecido como borda de transição na Eletrônica. Existem as bordas de subida e de descida, repre- 
sentando a alternância de “0º para “1º e vice-versa (WIDMER et al., 2017). 

Por fim, pode-se definir período, frequência e ciclo de trabalho de uma forma de onda di- 
gital. Essas características estão associadas à periodicidade da mesma e, em casos, extremos per- 


mitem uma aproximação por uma função aperiódica. A Figura 2.4 ilustra esse processo. 
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Figura 2.4 — Detalhamento e fórmulas de uma onda digital realística. 


F=14/T T=1/F 


Duty Cycle = Active pulse Width/Period = t,y/T 


Fonte: Editado de Widmer et al. (2017). 


2.1.3 PROCESSAMENTO LÓGICO POR CIRCUITOS 


Um circuito eletrônico lógico é um mecanismo composto de semicondutores e capaz de 
associar entradas específicas a saídas específicas. Isso é representado pela tabela-verdade, uma 
organização com todas as combinações possíveis de entradas que devem implicar em determinadas 


saídas, conforme a Figura 2.5 (WIDMER et al., 2017). 


Figura 2.5 — Tabela-verdade para o desenvolvimento de um circuito digital. 


Output 


Fonte: Widmer et al. (2017). 
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Entre os tipos de hardware para processamento digital, os fundamentais são as portas lógi- 
cas, listadas na Figura 2.6. Essas são as responsáveis, física ou virtualmente, por quaisquer cálculos 
binários ou aritméticos que um sistema digital, como uma calculadora, venha a realizar. Cada uma 
tem uma tabela verdade característica associada ao raciocínio humano básico: união, interseção, 
negação, equivalência etc. No âmbito dos computadores, elas estão presentes com destaque na 
ALU (Arithmetic Logic Unit, do inglês), parte interna de um microprocessador que efetua cálculos 


matemáticos para certas instruções serem executadas. 


Figura 2.6 — Simbologia para diferentes portas lógicas e suas respectivas operações. 


Fonte: Editado de Marston (2007). 


2.1.4 SISTEMAS DIGITAIS DE MEMÓRIA 


Quando um sinal de entrada é aplicado à maioria dos dispositivos ou circuitos, a saída de 
algum forma modifica em resposta à entrada, e quando o sinal de entrada é removido, a saída 
retorna ao seu estado original. Esses circuitos não exibem a propriedade de memória por que suas 
saídas voltam ao normal. Na eletricidade digital certos tipos de dispositivos e circuitos, de fato, 
têm memória. Quando uma entrada é aplicada a tal sistema, a saída muda sua condição, mas per- 
manecerá no novo estado mesmo após a entrada ser removida. A propriedade de manter a resposta 


para uma entrada momentânea é denominada memória. Ver a Figura 2.7 (WIDMER et al., 2017). 
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Figura 2.7 — Blocos representando sistemas com e sem a propriedade de memória. 


Nonmemory 
circuit 


Memory 
| | a circuit | 
Fonte: Widmer et al. (2017). 


Circuitos de memória têm um papel importante nos sistemas digitais, pois permitem o ar- 
mazenamento temporário ou permanente de números binários, com a habilidade de alterar a infor- 
mação guardada a qualquer instante. No escopo das memórias, incluem-se as ópticas e magnéticas, 
como CDs (Compact Disk, do inglês) e HDs (Hard Disk, do inglês), apesar de, nos sistemas ele- 
trônicos digitais, ser mais relevante dominar as memórias semicondutoras, como RAM (Random 
Access Memory, do inglês) e ROM (Read-Only Memory, do inglês). 

O príncipio de memória em circuitos digitais é dado pela noção de sequenciamento de sinais 
elétricos, o que é possível graças ao relógio ou clock, uma forma digital de referência. Esse dispo- 
sitivo permite dividir os circuitos de processamento digital em combinacionais — portas lógicas — e 
sequenciais, como clocked circuts com portas lógicas retroalimentadas e temporização por clock. 
A ideia de retroalimentação por temporização é ilustrada na Figura 2.8, para a unidade de memória 


que denomina-se latch ou flip-flop (WIDMER et al., 2017). 
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Figura 2.8 — O latch ou flip-flop SR, fundamento dos circuitos digitais de memória. 


A 
Pulse-steering NAND latch 
circuit 


Fonte: Widmer et al. (2017). 


Entre os dispositivos de memória, há os flip-flops SR, o básico, D, T e JK. No amplo con- 


texto de circuitos sequenciais, todos encontram aplicações, mas para armazenamento um deles des- 


taca-se: o flip-flop D. Essa unidade é projetada para tão somente armazenar um bit e trocá-lo com 


uma borda do sinal repetitivo de clock, sendo apropriada para a construção da estrutura semicon- 


dutora chamada registrador, representada na Figura 2.9. Seu papel é armazenar uma palavra binária 


inteira com certo tamanho e permitir sua manipulação. 


Figura 2.9 — Um registrador de 6 bits feito de flip-flops D com duas vias de controle. 


Fonte: Widmer et al. (2017). 
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A concatenação em matriz de vários registradores produz, em essência, uma memória se- 
micondutora convencional, como uma SRAM ou cache comercial. O detalhamento de uma memó- 
ria real, porém, é complexo por razões de densidade, que é a capacidade de armazenamento, custo 
de fabricação, volatilidade etc. A Figura 2.10 ilustra o processo de escrita e leitura de uma memória 


matricial genérica através de barramentos de endereço, para localização, e de dados, para definição 


de valor armazenado. 


Figura 2.10 — Memória genérica com controle através de lógica digital. 


Address register Data register 
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Address decoder Byte-organized memory array 


Address bus 


Data bus 


Fonte: Editado de Floyd (2015). 


Definições significativas no estudo prático das memórias são dadas a seguir. Através disso, 
é possível entender, fundamentalmente, como qualquer memória típica funciona sem um aprofun- 


damento em uma delas em particular (WIDMER et al., 2017). 


* Memória volátil: Qualquer tipo de memória que requeira a aplicação de energia elétrica a fim de 
guardar informação. Se a alimentação elétrica é retirada, os dados são todos perdidos. 
« Tempo de acesso: É o tempo entre a recepção, pela memória tratada, de uma nova entrada de 


endereço e o instante em que a informação é apresentada na saída da memória. 
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* Memória principal: Também referida como a memória de trabalho do computador. Ela 
guarda instruções e dados manipulados pela CPU no momento. 

* Memória cache: Um bloco de memória com alta velocidade entre uma memória principal 
mais lenta e os registradores — subunidades da CPU — do processador, de modo a otimizar a velo- 
cidade do computador. A cache pode ser fisicamente localizada na CPU ou na placa mãe, até 
mesmo em ambas. 

* Memória auxiliar: Também referida como armazenamento em massa porque guarda uma 
quantidade massiva de informação externa à memória principal. É maior em velocidade que a me- 
mória principal e sempre não-volátil. Os discos magnéticos são um exemplo comum. 

* Memória de acesso aleatório (RAM): Memória em que a localização física real de uma 
palavra de memória não tem efeito no tempo decorrido para a leitura ou escrita nesse local. A 
memória principal é tipicamente uma RAM e mais algumas do tipo cache. 

* Memória somente de leitura (ROM): Tecnicamente, uma ROM pode ser escrita ou pro- 
gramada apenas uma única vez, o que é normalmente feito em fábrica. Assim, informações só 
podem ser lidas desse tipo de memória, com ainda o fato de toda ROM ser não-volátil para arma- 
zenar dados. 

* Dispositivos de memória estática: Dispositivos de memória semicondutora em que da- 
dos armazenados ficarão permanentemente gravados enquanto uma alimentação elétrica existir, 
sem a necessidade de periodicamente reescrever a informação na memória. A SRAM é a memória 
RAM no caso estático, com característica transistorizada. 

* Dispositivos de memória dinâmica: Dispositivos de memória semicondutora em que 
dados armazenados não ficam guardados permanentemente, mesmo com a energia aplicada, a não 
ser que a informação seja periodicamente reescrita na memória, o que é denominado refresh. A 


DRAM é a memória RAM no caso dinâmica, com característica capacitiva. 


2.2 DEFINIÇÕES PARA SISTEMAS MICROPROCESSADOS 


No princípio da era digital, os circuitos eletrônicos lógicos eram feitos de tubos de vácuo, 
o que posteriormente foi substituído por transistores. Nessa época, alguns desses circuitos eram 


direcionados a controlar os sistemas computacionais como se fossem cérebros: surgiam as CPUs 
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(Central Processing Unit, do inglês), unidades centrais de processamento, capazes de realizar ta- 
refas básicas de aritmética, lógica e controle de dados (MALVINO; BROWN, 1992). 

Junto à CPU, eram aplicados outros tipos de circuitos para complementação. A memória, 
por exemplo, seria o local onde quaisquer dados ficariam armazenados a fim de serem continua- 
mente atualizados pela CPU. Ainda, os dispositivos I/O (Input/Output, do inglês), de entrada e de 


saída, serviam como auxiliares para a interpretação humana dos dados processados pela máquina. 


2.2.1 CONCEITO DE SISTEMA MICROPROCESSADO 


Etimologicamente, um microprocessador é um processador de dimensões físicas pequenas. 
Em geral, trata-se de uma CPU completa miniaturizada em um único circuito integrado de silício, 
que é por definição um circuito eletrônico capaz de interpretar e executar instruções, além de con- 


trolar entrada e saída (MALVINO; BROWN, 1992). 


Figura 2.11 — Visão simplificada de um sistema baseado em microprocessador. 


Input-output 


Fonte: Malvino; Brown (1992). 


Um sistema microprocessado, popularmente conhecido por computador, por sua vez, é um 
conjunto que contém um microprocessador e diversos subsistemas relacionados. Uma genérica or- 
ganização do tipo é ilustrada na Figura 2.11. 

Na prática, existem muitos tipos de computador, mas cada um pode ser quebrado nas mes- 
mas unidades funcionais. Cada unidade efetua funções específicas, com todas conjuntas a fim de 


funcionarem para executar as instruções descritas em um programa. A Figura 2.12 exibe, sob outra 
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perspectiva, as partes funcionais majoritárias de um sistema de hardware de computador, além de 


sua interação (WIDMER et al., 2017). 


Figura 2.12 — Perspectiva funcional de um sistema microprocessado genérico. 


Central processing 
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Fonte: Widmer et al. (2017). 


As funções majoritárias do sistema microprocessado são as seguintes unidades de cada tipo: 


* Entrada: Através dessa unidade, um conjunto completo de instruções e dados é inserido 
no sistema e na unidade de memória, para ser armazenado até ser necessário. A informação tipica- 
mente entra na unidade de entrada por um teclado, um disco ou vários sensores. 

* Memória: A memória armazena as instruções e dados recebidos pela unidade de entrada. 
Ela guarda o resultado de operações aritméticas recebidas da unidade aritmética. Ela também supre 
informação para a unidade de saída. 

* Controle: A unidade absorve instruções da unidade de memória, uma de cada vez, e in- 
terpreta-as. Ela então envia sinais apropriados para todas as outras unidades para causar a execução 
de uma instrução específica. 

* Lógica e Aritmética: Todos os cálculos aritméticos e decisões lógicas são efetuados nessa 
unidade, que é capaz de mandar resultados para a unidade de memória armazenar. 

* Saída: Essa unidade capta dados da unidade de memória e imprime, exibe ou, em casos 
distintos, apresenta a informação ao operador, podendo envolver um processamento posterior de 


dados. 
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As unidades de controle e lógica-aritmética são frequentemente consideradas um conjunto, 
que é a própria e conhecida CPU ou unidade central de processamento. A CPU, então, contém 
todos os circuitos para captação e interpretação de instruções, com ainda a responsabilidade de 


controlar e efetuar várias operações exigidas pelas instruções correntes. 


2.2.2 DERIVADOS DE PROPÓSITOS DIVERSOS 


O termo microprocessador veio primeiro à tona com o uso pela Intel em 1972 e, em geral, 
refere-se à implementação das funções de uma unidade central de processamento em um, único e 
compactado em larga escala, circuito integrado. Um microcomputador, como na Figura 2.13, por- 
tanto, é por definição um computador construído a partir de um microprocessador e alguns outros 
componentes de memória e entrada-saída ou I/O. 

O antigo Intel 4004 permitia a montagem de um microcomputador de quatro chips consti- 
tuído de uma CPU, uma memória de leituras — ROM — para programas, uma memória de escrita- 
leitura — RAM -— para dados e um registrador de deslocamento para expansão de saídas (CADY, 


2010). 


Figura 2.13 — Leiaute básico de um sistema de microcomputador digital. 
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Fonte: Huggins (1981). 
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Há também o chamado microcontrolador o qual é um microcomputador composto de CPU, 
memória e I/O, com todas as partes elétricas dentro de um único chip de semicondutor. Este é 
utilizado em aplicações embarcadas, sistemas dedicados a uma única tarefa ou único grupo das 
mesmas. É normal que estas sejam aplicações de controle que, por isso, fazem uso de microcon- 
troladores, como torradeiras, fornos de micro-ondas e automóveis. 

A gama de sistemas microprocessados expande-se ainda para o que é denominado de lógica 
programável. Indo de pequenos dispositivos que substituem alguns circuitos digitais de funções 
fixas até dispositivos complexos e de alta densidade que substituem milhares de dispositivos de 
funções fixas. Entre eles, o PLD (Programable Logic Device, do inglês) e o FPGA (Field-Pro- 
grammable Gate Array, do inglês), além de outros sistemas incorporam, de certa maneira, um ou 


mais microprocessadores (FLOYD, 2015). 


2.2.3 ARQUITETURAS DE MICROPROCESSADORES 


A memória de um microcomputador, microprocessador ou microcontrolador guarda ambos 
dados e instruções. Instruções precisam mover-se sequencialmente através da CPU para serem de- 
codificadas e executadas. Dados podem ser lidos da memória pela CPU ou escritos na memória 
pela CPU. Portanto, o raciocínio pelo qual a memória é organizada e o jeito que se comunica com 
a CPU determina a performance do dispositivo. Os modelos genéricos para hardware são as arqui- 
teturas, que focam na estrutura de memória, são a von Neumann e Harvard (VALDÉS-PÉREZ; 
PALLAS-ARENY, 2009). 

Um computador padrão é mostrado na Figura 2.14. Este é composto elementarmente por 
uma CPU, unidade de processamento, memórias RAM e ROM contendo o programa e os dados, 
uma interface I/O associada a portas de entrada e de saída, e, por fim, três barramentos digitais 
conectando o sistema inteiro. A organização do programa e dados em um único bloco de memória 
é chamado arquitetura von Neumann, em homenagem a John von Neumann, que descreveu esse 
computador de propósito geral e armazenador de programas em 1945 (CADY, 2010). 

Na Figura 2.14, os barramentos de dados, de endereço e de controle são diversos fios elé- 
tricos, por exemplo 8, 16, 32 ou mais, que carregam sinais binários de um local a outro no sistema 


computacional. Esse é o diagrama de blocos de um sistema de computador clássico, amplamente 
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aplicado em computadores pessoais. 
Figura 2.14 — Diagrama da arquitetura computacional von Neumann. 
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Fonte: Cady (2010). 


Há, ainda, outro tipo de arquitetura de computadores majoritária, que é a Harvard. Em tal 
forma de organização, são funcionais duas memórias completamente separadas, ou seja, uma para 
dados e outra independente para o programa. Essa arquitetura é frequentemente encontrada em 
chips para processamento digital de sinais e alguns microcontroladores como os da família PIC da 


Microchip Technology. Isso é ilustrado na Figura 2.15 (CADY, 2010). 
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Figura 2.15 — Diagrama da arquitetura de embarcados Harvard. 
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Fonte: Cady (2010). 


A Figura 2.16 compara esses dois modelos. A arquitetura von Neumann usa menos linhas 
que a arquitetura Harvard, fazendo assim uma conexão mais simples entre memória e CPU. Entre- 
tanto, essa estrutura não permite manipulação simultânea de instruções e dados pelo fato de só 
haver um barramento. Por outro lado, a arquitetura Harvard permite o manejo concorrente de partes 
do programa, uma vantagem em termos de velocidade da execução. 

Em um microcomputador, a CPU é o próprio chip microprocessador, por que ele combina 
dados e programa em única memória. Uma CPU implementada por von Neumann precisará de 
menos pinos, o que reduz seu tamanho. Essa é a razão de computadores pessoais serem projetados 
em sua maioria com essa arquitetura. Entretanto, a situação é diferente em um microcontrolador, 
pois os componentes do sistema são localizados dentro de um mesmo chip integrado e, então, não 
há necessidade de minimização de pinos. Por essa razão Harvard é o modelo da maioria dos mi- 


crocontroladores, como os da família PIC (VALDÉS-PÉREZ; PALLAS-ARENY, 2009). 
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Figura 2.16 — Comparação entre as arquiteturas de hardware von Neumann e Harvard. 
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Fonte: Valdés-Pérez; Pallas-Areny (2009). 


Finalmente, outra classificação de arquitetura de microprocessadores, mas que já é mais 
específica para programadores, é a entre RISC (Reduced Instruction Set Computer, do inglês) ou 
CISC (Complex Instruction Set Computer, do inglês) que indicam, respectivamente, um conjunto 
de instruções reduzido ou complexo. O primeiro é mais rápido por consumir únicos ciclos de clock 


de processador por instrução, enquanto o outro faz uso de múltiplos. 


2.2.4 PROGRAMAÇÃO NA ELETRÔNICA DIGITAL 


Programação é um campo proximamente relacionado à Eletrônica, em geral. O que incen- 
tivou à criação dos circuitos eletrônicos digitais foi a necessidade de fabricar uma máquina com 
partes não-móveis que pudesse realizar cálculos matemáticos. Conectando vários circuitos, com o 
tempo foi alcançado o resultado esperado, que era uma máquina muito mais rápida que a calcula- 
dora mecânica (MALVINO, BROWN; 1992). 


Após a máquina eletrônica de cálculos ter sido realizada, surgiu a prioridade de possibilitar 
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maneiras de comandar a máquina a efetuar operações específicas. Em princípio, conexões elétricas 
de comutações condicionais foi o começo da seletividade da máquina, técnica que foi substituída 
posteriormente por algoritmos em linguagens de programação. 

Atualmente, qualquer profissional ou entusiasta da área de sistemas eletrônicos deve ter 
noções de como programar um microprocessador, visto que este tornou-se com o tempo insepará- 
vel de seu programa. A complexidade dos microprocessadores integrados fez este cenário ser pos- 


sível, não podendo ser tratada como no caso de uma simples calculadora. 


2.3 ARQUITETURA E PADRÕES DE BARRAMENTOS 


Dentro de sistemas baseados em microprocessador, como embarcados, há numerosos com- 
ponentes, tais como a CPU, memórias, controladores de disco etc. Inevitavelmente esses compo- 
nentes precisam trocar informações entre si, sendo esses dados movidos de um componente a outro 
através de interconexões, com o nome de barramentos. 

No começo do século XI, o barramento série passou a, gradativamente, substituir o tipo 
paralelo para fins de maior throughtput ou taxa de comunicação de dados. Nesse contexto, os pa- 
drões de barramentos mais empregados são: PCI, USB, RS-232, 2C e SPI, além de USART para 
microcontroladores (CHANGYI, 2016). 


2.3.1 DEFINIÇÃO DE BARRAMENTO 


Um barramento permite dois ou mais dispositivos comunicarem entre si, em geral com o 
propósito de transmitir informação. E um conjunto de fios e conectores físicos unido a um conjunto 
de especificações elétricas, podendo ser tanto internos quanto externos a um sistema. Um barra- 


mento típico é exibido na Figura 2.17. 
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Figura 2.17 — Conceito e características de um típico barramento digital. 
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Fonte: Floyd (2015). 


As propriedades físicas de um barramento típico incluem o número de fios ou condutores 
PCB, a configuração e comprimento dos fios ou condutores, e os tipos e configurações dos conec- 
tores. As propriedades elétricas de um barramento típico incluem, mas não são limitadas a, algumas 
ou todas das seguintes: formato do sinal, níveis de tensão do sinal, frequência de clock, rapidez de 
transferência de dados, largura de faixa, formato de frame de dados, taxa de dados, protocolo han- 
dshaking, detecção de erros, impedâncias e terminação de linha (FLOYD, 2015). 

Cada dispositivo conectado ao barramento precisa ser compatível com as especificações do 
barramento para se comunicar. Um dispositivo que envia dados também pode ser um dispositivo 


receptor, e vice-versa. 


2.3.2 COMUNICAÇÕES EM SÉRIE E PARALELO 


A transmissão série de informações ocorre quando os dados são enviados com um bit por 
vez em um stream — campo de comunicação — de unidades binárias. Já a transmissão paralela ocorre 
quando um vetor ou pacote de bits é transmitido em cada instante. Esses aspectos são ilustrados na 
Figura 2.18. 

Geralmente, dados são processados em paralelo por computadores mas são transmitidos em 


série para sistemas externos. Por exemplo, as páginas de um computador para uma impressora 
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tipicamente são mandadas via USB, isto é, em série. O mesmo costuma ser válido para dados trans- 


mitidos em longas distâncias através de uma mídia ou aparelhato de transmissão (FLOYD, 2015). 


Figura 2.18 — Dígitos binários organizados nos casos série e paralelo. 
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Fonte: Editado de Floyd (2015). 


Para os barramentos digitais, classifica-se como série ou paralelo. Um barramento paralelo 
carrega bits de informação simultaneamente, enquanto que um barramento série movimenta bits 


de dados sequencialmente um de cada vez. Isso é comparado na Figura 2.19. 


Figura 2.19 — Esquemas de funcionamento dos barramentos paralelo e série. 
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Fonte: Editado de Floyd (2015). 


É fato que, aparentemente, barramentos paralelos são mais rápidos pelo fato de poderem 


transmitir pacotes binários por instante. Porém, em muitas situações de taxas de transmissão mais 
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elevadas, os do tipo série são mais rápidos que o tipo paralelo por fatores como interferência ele- 
tromagnética e efeitos de temporização (FLOYD, 2015). 

Geralmente, dados são processados em paralelo por computadores, entretanto são transmi- 
tidos em série para sistemas externos. Conversões série-paralelo e paralelo-série são, assim, fre- 
quentes em circuitos de comunicação digitais. 

É comum que se use registradores de deslocamento, por terem entradas e saídas do tipo 
série e paralelo, para realizar essas funções, em que as células de memória são acionadas para 
armazenar bits na ordem imposta. Com os símbolos *S”, “P”, “T” e “O” abreviando respectivamente 
os termos “série”, “paralelo”, “entrada” e “saída”, pode-se classificar, de acordo com a Figura 2.20, 
os registradores de conversão entre série e paralelo (WIDMER et al., 2017). 

As nomenclaturas dos registradores de deslocamento são PIPO (Parallel Input, Parallel 
Output, do inglês), SISO (Serial Input, Serial Output, do inglês), PISO (Parallel Input, Serial Ou- 
tput, do inglês) e SIPO (Serial Input, Parallel Output, do inglês), sendo de acordo com o significado 


individual de cada letra. Na Figura 2.20, tais composições são ilustradas, de cima para baixo. 
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Figura 2.20 — Registradores de deslocamento: PIPO, SISO, PISO e SIPO. 
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Fonte: Widmer et al. (2017). 


2.3.3 OPERAÇÕES POR TEMPORIZAÇÃO 


Na transmissão assíncrona, a informação é enviada em pequenos agrupamentos, que são 


denominados pacotes. Tipicamente, muitos deles são necessários para formar uma mensagem in- 


teira. Um pacote de dados consiste em bits de dados representando caracteres alfanuméricos, um 


bit de paridade e bits de início/parada. Existe uma pausa entre os pacotes de dados tal que o receptor 


reconheça o bit de início de cada pacote. No fim de cada pacote, há um ou mais bits de parada para 


indicar ao receptor o final da leitura. 


Em sistemas assíncronos, os dispositivos de envio e recepção funcionam através de oscila- 


dores que têm idêntica frequência de clock. Para evitar desvios de frequência, nos bits de início dos 


pacotes é comum haver recorrentes sincronizações (FLOYD, 2015). 
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E chamado de barramento assíncrono aquele que não possui clock, podendo servir para 
dispositivos com diferentes taxas de clock. Nesse caso, costuma-se aplicar o protocolo de barra- 
mento — conjunto de regras operativas — handshaking, que tem como princípio o acordo mútuo para 


a transmissão, conforme a Figura 2.21. 


Figura 2.21 — Protocolo handshaking para barramentos assíncronos. 


Requesting Responding 


device (master) device (servant) 


(1) Master sends request for data (REQD) to servant. 
(2) Servant sends an acknowledgement (ACK) and places data on bus. 
3) Master receives data and removes request. 


EN ú E 
(4) Servant removes acknowledge and is ready for next request. 


Fonte: Floyd (2015). 


As transmissões digitais síncronas, por sua vez, são definidas pelo ajuste de tempo de um 
sinal de clock único, conforme as ordens do transmissor e receptor do sistema. Os bits são manda- 
dos em agrupamentos contínuos sem pausas, o que significa que o receptor deve saber onde começa 
e onde termina o bloco de dados. 

O reconhecimento da leitura de dados, no caso síncrono, é solucionado descobrindo o 
tempo correspondente ao início do pacote, além dos intervalos entre os bits. Com isso, o receptor 
é sincronizado com o transmissor, diferentemente da operação assíncrona. É comum que os siste- 
mas síncronos enviem mais de um 8 bits de dados e sejam mais rápidos que os assíncronos 
(FLOYD, 2015). 

Os denominados barramentos síncronos, diferente dos assíncronos, incluem um clock nas 
linhas de controle e têm um protocolo de comunicação fixo, relativo ao relógio global. Têm as 


qualidades de serem dependentes de clocks específicos e de comprimentos curtos de condutores a 


53 


MICROPROCESSADORES E TECNOLOGIAS APLICADAS 


fim de carregar sinais de alta frequência. 


2.3.4 BARRAMENTOS PADRONIZADOS 


Um barramento não é apenas um conjunto de conexões físicas, ou seja trilhas PCB ou ca- 
bos, mas é também uma união de sinais e parâmetros de operação que são definidos na especifica- 
ção do barramento. Quaisquer dispositivos conectados para um dado barramento precisam ser com- 
patíveis com as especificações dele. A partir disso, pode-se estudar diversos padrões de barramen- 


tos existentes e importantes. 


2.3.4.1 USART 


Comunicação serial é o processo de enviar múltiplos bits de dados através de um fio ou 
canal único. Trata-se de uma referência ao telégrafo original, em que os bits eram os pontos e os 
traços do código Morse. Os bits de um byte serial são separados pelo tempo de modo que o receptor 
possa determinar os níveis lógicos de cada bit (BARNETT et al., 2007). 

A forma usual de comunicação serial é a assíncrona, no sentido que um sinal de clock co- 
mum não é requerido em ambos transmissor e receptor para haver a sincronização da detecção de 
dados. A comunicação serial assíncrona utiliza o bit de início e o bit de parada adicionados ao byte 
de informação para permitir ao receptor identificar a temporização de cada bit, como na Figura 


Dododa 
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Figura 2.22 — Forma de onda serial em barramento USART, com dado de 8 bits. 


Logic 1 
Logic O 
State Idle Idle | Active | Active | Active | Active | Active | Active | Active | Active | Active | Active | Idle 
Logic Level 1 1 0 1 0 0 0 0 0 | 0 1 1 
Bit Type Start | Data | Data | Data | Data | Data | Data | Data | Data | Stop 
Data Bit Number 0 1 2 3 4 5 6 7 


Fonte: Barnett et al. (2007). 


No padrão USART (Universal Synchronous Asynchronous Receiver-Transmitter, do in- 
glês), toda a temporização relativa à formatação do byte serial, a amostragem dos bits seriais e 
adição dos bits de início e parada são manipulados automaticamente, sem a necessidade de inter- 
venção de um programador. Especificamente, o que deve ter verificação humana é tão somente a 
compatibilidade entre transmissor e receptor, no tocante ao número correto de bits de dados, co- 
mumente 8 bits, determinando quando ou não incluir um bit de paridade — normalmente não — e a 
definição da taxa de comunicação conhecida como Baud Rate, o inverso do tempo por bit (BAR- 
NETT et al., 2007). 

A prevalência do USART dá-se majoritariamente em microcontroladores para sistemas em- 
barcados, como os da família PIC. Sua simplicidade de início e fim através de transições digitais, 
além de aplicação de canal único para o dado, torna-o adequado para aplicações eletrônicas com 
ondas de rádio, fios elétricos, infravermelho etc. Pelo caráter assíncrono dominante, costuma ser 
alternativa a nomenclatura UART para esse padrão. 

Para o UART, genericamente, em um microcontrolador ocorre o envio de dados por meio 
de uma interface I/O paralela e interna para um buffer — armazenador temporário — de transmissão 


de dados. Essa informação é transferida para um registrador de deslocamento do tipo PISO. Dados 
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seriais, então, são movidos por clock pela linha de sinal TxD, no transmissor. A informação serial 
é recebida pela linha de sinal RxD, no receptor, onde então passa por um registrador de desloca- 
mento SIPO. Ao serem transferidos para um buffer de recepção de dados, o microcontrolador fica 


apto a fazer uma operação de leitura, assim aproveitando os bits comunicados (CADY, 2010). 


2.3.4.2 R$-232 


Denomina-se R$-232 um dos primeiros padrões de barramento digital. Como meio mais 
comum de interfaceamento entre sistemas microprocessados, ele foi desenvolvido a fim de prover 
maior distância para uma razoável comunicação serial utilizando fios para portar o sinal. O RS-232 
é um esquema invertido, em que o nível lógico 1 é representado por uma tensão negativa mais 
negativa que -3 V, enquanto o nível lógico O é representado por uma tensão positiva mais positiva 
que 3 V. Usando uma tensão não-nula e diferente para cada nível lógico é uma técnica que permite 
checar erros de hardware, pois uma linha quebrada apresentaria O V no receptor, podendo então 
ser detectada. É clássico que comunicações entre microcontroladores e PCs sejam via RS-232 
(BARNETT et al., 2007). 

Também conhecido por EIA-232, o barramento R$-232 já foi a referência para toda cone- 
xão entre computadores e equipamentos periféricos. Capaz de operar como síncrono ou assíncrono, 
foi em grande parte substituído pelo USB devido a sua velocidade limitada, requerimento de ten- 
sões elevadas e grande tamanho do conector. Entretanto, dispositivos R$-232 ainda são presentes 
em aplicações industriais e de telecomunicações, assim como na instrumentação científica. 

Os dispositivos ligados por um barramento RS-232 são classificados como DTE (Data Ter- 
minal Equipment, do inglês), normalmente um PC ou computador pessoal, e DCE (Data Commu- 
nication Equipment, do inglês), um sistema embarcado. Como novos computadores não têm portas 
R$S-232, aplica-se conversores de USB para R$-232, se necessário para equipamentos antigos. A 


Figura 2.23 ilustra um conector convencional de 9 pinos (FLOYD, 2015). 
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Figura 2.23 — Conectores macho e fêmea para cabo R$-232, para o DTE e o DCE. 


Pino Sinal Direção Descrição 
DCD DTE <- DCE Detectar portador de informação (quando conectado). 
RxD DTE <- DCE Dados recebidos (enviados a partir do DCE). 
TxD DTE -> DCE Dados transmitidos (enviados a partir do DTE). 
DTR DTE -> DCE Informação terminal pronta (para conexão). 
Referencial de terra comum. 
DSR DTE <- DCE Informação conjunta pronta (para conectar). 
RTS DTE -> DCE Requisitar para enviar (ou DTE pronto para receber). 
CTS DTE <- DCE Esclarecer para enviar (ou DCE pronto para receber). 


Do aus wnNm 
[ny 
4 
|) 


RI DTE <- DCE Tocar indicador (para chamadas de entrada). 


Fonte: Ethernut Project (2014). 


Do ponto de vista técnico, o R$-232 tem uma taxa máxima de dados de 20 kbps, além de 
um cabo de comprimento máximo de 50 pés. O formato da informação tipicamente consiste de 77 
ou 8 bits de dados, um bit de início, um bit de paridade ocasional conforme o protocolo, e um bit 
de parada. Normalmente, uma faixa de +5V a +15V representa o bit O e uma faixa de -5V a -15V 
representa o bit 1, eletricamente, como na Figura 2.24. 

Muitas vezes, o termo UART é usado para referir a uma porta serial assíncrona que suporta 
padrões RS-232. Muitos microcontroladores são compatíveis com vários periféricos por oferece- 
rem portas UART. Entretanto, por mais que sejam logicamente compatíveis, as faixas de tensão 
elétrica são distintas. O padrão UART frequentemente está associado a microprocessadores em 
torno de 1,8 V e 3,3 V, enquanto uma porta RS-232 real poderia variar de -15 Va +15 V. Por isso, 


um circuito transceptor é relevante para adaptar tensões, além de proteções (CHANGYI, 2016). 
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Figura 2.24 — Formato da informação transmitida por um barramento RS-232. 


+15 V 
(0) 
-15V 
(1) 
Start bit Stop bit 
(0) (1) 


Fonte: Floyd (2015). 


2.3.4.3 DC 


O DC foi primeiro introduzido pela Philips, atual NXP, Semiconductors como um padrão 
de barramento de dois fios para interconexão de dispositivos. O mesmo possui dois fios de sinais 
operando em modo OD (Open Drain, do inglês) para alcançar comunicação bidirecional entre dis- 
positivos mestre e escravo. Por ser sucinto, o barramento DC foi amplamente utilizado como in- 
terface em série para memórias, sensores de temperatura, controladores LED encapsulados, entre 
outros (CHANGYI, 2016). 

Os dois fios condutores aplicados em um barramento I2C são denominados SCL (Serial 
Clock Line, do inglês) e SDA (Serial Data Line, do inglês). Pelo fato de operarem em modo OD, 
eles são definidos em nível lógico ALTO ou 1 por padrão, através de resistores de pull-up. Cada 
um dos dispositivos escravos deve ser programado com um endereço de 77 bits para unicamente se 
identificar no barramento, além de toda a transação de dados incluir diferentes estágios: START, 
ADDRESS, R/W, ACK, DATA, STOP; como na Figura 2.25. 

Todas as transações no padrão I2C são controladas pelo mestre e são formadas por uma 
condição START, um endereço de escravo e um bit representando escrita ou leitura — bits “0” e “1”, 


respectivamente — terminando por STOP. Há três tipos básicos de mensagem no I2C (FTDI, 2017): 


º Mensagem singular em que o mestre escreve dados no escravo; 
. Mensagem singular em que o mestre lê a partir do escravo; 
. Mensagens combinadas, com o mestre manipulando pelo menos duas leituras 


58 


MICROPROCESSADORES E TECNOLOGIAS APLICADAS 


ou escritas de um ou mais escravos distintos conectados. 


Figura 2.25 — Formas de onda de um barramento I2C, para cada um dos condutores. 
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Fonte: Changyi (2016). 


2.3.4.4 SPI 


O SPI (Serial Peripheral Interface, do inglês), literalmente uma interface em série para 
periféricos. Esse padrão é de quatro fios com transmissão bidirecional nos dois sentidos, sendo um 
protocolo produzido pela Motorola Semiconductor, atual parte da NXP. Os condutores são deno- 
minados: SCLK (Serial Clock, do inglês), SSH (Slave Select, Active Low, do inglês), MOSI (Master 
Output, Slave Input, do inglês) e MISO (Master Input, Slave Output, do inglês). 


Figura 2.26 — Relação entre os dispositivos SPI mestre e escravo. 
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Fonte: Changyi (2016). 
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O condutor ou porta SSH serve como uma seleção para indicar a disponibilidade de uma 
gama de dados. Um tráfego de dois caminhos pode ocorrer em MISO e MOSI ao mesmo tempo 
em que SS& é confirmado. O diagrama de temporização entre o mestre e o escravo SPI é ilustrada 
na Figura 2.26. 

O barramento SPI oferece a flexibilidade para mudar a polaridade de clock CPOL e a ângulo 
de clock CPHA, que determina os limites de amostragem de fato. Porém, discrepante quanto a 
outros padrões, o SPI não tem uma organização central para todos os detalhes de operação, o que 


faz com que alguns fabricantes difiram, por exemplo, no HSS (CHANGYI, 2016). 


2.3.4.5 USB 


Apesar de haver diversos padrões de barramento disponíveis, o USB (Universal Serial Bus, 
do inglês) é um dos mais usados, sobretudo para conectar periféricos. Existem tipicamente duas ou 
mais portas USB em computadores modernos e, com hubs USB, até 127 dispositivos podem ser 
conectados. O padrão USB possibilita a conexão e remoção enquanto o computador funciona, o 
que é denominado hot swapping (FLOYD, 2015). 

O padrão USB original era o 1.0, que foi seguido pelo 1.1. O USB 2.0 substituiu as duas 
versões anteriores e recentemente o USB 3.0 foi introduzido. As versões anteriores ainda estão em 
uso, sobretudo a 2.0. Em termos de consumo de dado, o USB tem quatro classificações, que são 


apresentadas na Figura 2.27. Em comprimento de cabos, o USB é descrito na Figura 2.28. 


Figura 2.27 — Modos de operação USB e taxas de transmissão máximas deles. 


Low-Speed Full-Speed High-Speed ' Super-Speed Data Rate Maximum Value 
USB 1.0 , . Low-speed 0.1875 MBps 
USB 1.1 e . Full-speed 1.5 MBps 
USB 2.0 . . . High-speed 60 MBps 
USB 3.0 e º e . Super-speed 625 MBps 


Fonte: Floyd (2015). 
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Figura 2.28 — Dados sobre comprimentos de cabos adaptados ao padrão USB. 


USB 1.1 USB 2.0 USB 3.0 
Max cable length 9.8 ft. (3.0 m) 16.4 ft. (5.0 m) 9.8 ft. (3.0 m) 
Maximum total length 49.2 ft. (15 m) 82.0 ft. (25 m) 49.2 ft. (15 m) 


Fonte: Floyd (2015). 


Em termos de cabos e conectores, as versões até a 2.0 possuem um cabo de quatro fios 
blindados, incluindo um par trançado para reduzir ou eliminar ruído para a transmissão de dados, 
um fio de +5 V fixo e um fio colorido de referência de terra. O USB 3.0 já apresenta nove fios, 
apesar de ser virtualmente compatível com o 2.0. Diferentes conectores USB são detalhados na 


Figura 2.29, além da nomenclatura de cada conexão elétrica. 


Figura 2.29 — Um cabo USB típico até a versão 2.0 e os tipos de conectores disponíveis. 


1 


Gnd D+ D- +5V 


Fonte: Floyd (2015). 


Em USB, um dispositivo ou device é uma unidade física ou lógica que efetua uma função 


particular. Dispositivos incluem hubs, teclados e impressoras. O host, normalmente um computa- 
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dor pessoal, atribui um único endereço para o dispositivo no USB. É comum que o conector retan- 
gular ou 4 Form seja ligado no lado do computador, enquanto o conector poligonal ou B Form seja 


ligado no device, um sistema embarcado. Representação na Figura 2.30 (JOUANEH, 2013). 


Figura 2.30 — Um cabo USB drena até 500mA no padrão 2.0 e 900mA no padrão 3.0. 


A Form 


” 


— B Form 


Fonte: Jouaneh (2013). 


Quanto à transferência de dados, há quatro modos de operação para USB: de controle, de 
massa, de interrupção e isocrônico. O modo de controle é usado para obter informação sobre o 
dispositivo e para definir seu endereço do dispositivo, além dos parâmetros de configuração. O 
modo de massa é tipicamente usado em aplicações nas quais a transferência de dados não é crítica, 
como enviar dados para uma impressora ou receber de um scanner. O modo de interrupção é usado 
quando há latência em um dispositivo, como em teclados e mouses. No modo isocrônico, a taxa de 
transmissão de dados é constante e ele é aplicado em sistemas de áudio e vídeo diversos. Os dife- 
rentes modos são relacionados em termos de detecção de erros, recuperação e largura de faixa. É 
interessante frisar que toda transferência de dados USB é iniciada pelo computador de host 
(JOUANEH, 2013). 

Os dados seriais, em um barramento USB, são transmitidos em um par trançado rotulado 
por D+ e D-. Eles são transmitidos utilizando a codificação conhecida por NRZI com níveis de 3,3 
V, sendo 6,6 V diferencial entre as duas linhas. Um formato de pacote pode conter os seguintes 


campos: 
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* Sync: Sincroniza o clock do receptor com o transmissor, com tamanho conforme a taxa. 
* PID: Identifica o tipo de pacote a ser transmitido. 

* ADDR: Especifica a que dispositivo o pacote deve ser enviado. 

* Data: Campo de pura informação útil, de até 1024 bytes de dados. 

* ENDP: Manipulador de endpoints, ou seja, fontes ou absorvedores de dados. 

* CRC: Verifica erros de redundância cíclica na informação dentro do pacote. 


* EOP: Campo que sinaliza o fim de um pacote, em termos de acesso. 


Há quatro tipos de pacote USB, que são token, data, handshake e start-of-frame, como mos- 
trado na Figura 2.31 com o formato de cada tipo de pacote. Um pacote token indica o tipo de 
transação, um pacote data contém informação real, um pacote handshake identifica uma transação 


e o pacote start-of-frame começa um novo processo (FLOYD, 2015). 


Figura 2.31 — Formatação para pacotes de dados transmitidos por um barramento USB. 


Sync | PID | ADDR| ENDP | CRC Sync | PID | Data | CRC | EOP 
8/32 8 7 4 5 8/32 8 |0-8192] 16 3 


Token packet Data packet 


Sync | PID | Frame number | CRC | EOP 
8/32 8 Il 5 3 


Handshake packet Start-of-frame packet 


Fonte: Floyd (2015). 
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2.3.4.5 PCI 


O PCI (Peripheral Component Interconnect, do inglês) possui o objetivo básico de interco- 
nectar componentes periféricos, conforme seu acrônimo indica. É um barramento interno e sín- 
crono para interconexão, como na Figura 2.32, de chips, placas de expansão e subsistemas de pro- 
cessamento e memória. O barramento PCI original teve a espessura de 32 bits e frequência de 33 
MHz. Outra versão tem uma espessura de 64 bits e frequência de 66 MHz. Versões da época já 
possibilitavam transferência de dados de 64 bits usando um clock de até 133 MHz para permitir 


larguras de faixa de até 1066 MBps. 


Figura 2.32 — Placa de circuito impresso com vários slots para barramento PCT. 


ER 


Fonte: Direct Industry (2017). 


O padrão PCI original requeria 5 V para energia e níveis de sinais. Como o padrão evoluiu, 
a opção 3,3 V foi adicionada. O último padrão provido foi para somente 3,3 V. O conector PCI de 
32 bits tem 62 pinos e 124 contatos, com 62 por lado. Um número de 32 dos contatos são usados 
para ambos endereço e informação, ambos multiplexados. Os demais pinos são aplicados para si- 
nais de comando e controle, alimentação, aterramento etc. O conector de 64 bits já tem um adicio- 


nal de 32 bits para um total de 94 (FLOYD, 2015). 
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2.4 PROCESSADORES PARA SISTEMAS EMBARCADOS 


Um sistema embarcado é um sistema eletrônico ou eletromecânico projetado para efetuar 
uma função específica e é uma combinação de ambos hardware e firmware, um software gravado. 
Toda aplicação embarcada — embedded - é única e o hardware, assim como o firmware, é altamente 
especializado para o domínio da aplicação. Esses tipos de sistemas tem se tornado uma parte ine- 
vitável de qualquer produto ou equipamento em todas as áreas: aparelhos eletrodomésticos, tele- 
comunicações, equipamento médico, controle industrial, produtores de consumidor etc (SHIBU, 
2009). 

Os sistemas embarcados já existiam desde antes da revolução da tecnologia da informação. 
Antigamente, embarcados eram construídos com tubos de vácuo e lógicas de transistores, com 
algoritmos implementados em baixo nível. Com o avanço na tecnologia dos semicondutores, o 
desenvolvimento de sistemas embarcados miniaturizados foi estimulado. Nesse cenário, surgem os 
microcontroladores, que são projetados para incorporarem os vários detalhes de um sistema micro- 


processado em uma única pastilha semicondutora. 


2.4.1 PLACA DE CIRCUITO IMPRESSO 


Uma PCB (Printed Circuit Board, do inglês) é uma plataforma destinada a locar compo- 
nentes eletrônicos e eletromecânicos e interconectá-los sem fios condutores discretos. Uma placa 
de circuito impresso consiste de partes condutivas, chamadas trilhas, e leiautes de componentes 
anexados a folha isolante, referida como substrato. Um leiaute de PCB finalizado é muito seme- 


lhante ao que seria a PCB física, como mostra a Figura 2.33. 
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Figura 2.33 — Placa de circuito impresso, com ênfase na locação dos componentes. 
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Fonte: Express PCB (2015). 


O passo final no projeto de hardware é a fabricação da PCB. Para executá-la, toda a infor- 
mação contida no leiaute deve ser transferida para a ferramenta de fabricação da PCB, em um 
formato compreensível. Um arquivo Gerber, criado a partir do leiaute virtual, é aceito universal- 
mente como padrão para transferir informações de coordenadas e trilhas, além de detalhes sobre 


componentes e furos, para fabricações de PCB (SHIBU, 2009). 


2.4.2 CONCEPÇÃO DE SISTEMA EMBARCADO 


Diferentes de um sistema computacional de propósito geral, os sistemas embarcados pos- 
suem certas características específicas que são únicas para cada embarcado. Algumas das mais 
importantes são: aplicação e domínio específico; tempos real e reativo; operação em ambientes 
conturbados; distribuição; tamanho e peso pequenos; e, características de energia. 

Ao analisar de perto, nota-se que qualquer sistema embarcado tem certas funções para efe- 
tuar e são desenvolvidos de tal maneira a fazer somente as funções pretendidas. Assim, eles não 
devem ser usados para propósitos distintos do designado em projeto. Essa característica de aplica- 


ção e domínio próprio faz com que, a título de exemplificação, não se troque unidades de controle 
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entre um forno de micro-ondas e um ar-condicionado (SHIBU, 2009). 

Os sistemas embarcados também estão sempre em contato com o mundo real e seu tempo 
através de sensores e dispositivo de entrada definidos por usuário, que são conectados à porta de 
entrada do sistema. Ainda, eles são projetados para serem reativos, com seu tempo reativo corres- 
ponde a variações da saída conforme a entrada (SHIBU, 2009). 

Os sistemas embarcados devem ser aplicados em ambientes controlados. Por isso, devem 
ser construídos de modo a exercerem suas funções mesmo em ambientes repletos de perturbações, 
às quais devem ser internamente tratadas pelo embarcado. Outra noção é a de sistemas embarcados 
distribuídos, o que significa menores comporem maiores, ou seja, sistemas embarcados em larga 
escala serem compostos por unidades embarcadas menores. 

Finalmente, certas qualidades são mais superficiais, mas ainda relevantes. Esse é o caso da 
miniaturização em geral dos sistemas embarcados, que, além de estar associada com seu consumo 
por um comprador, ainda é central para a operação em sistemas distribuídos. Como os sistemas 
devem ser pequenos e baratos, o consumo de energia deve ser trabalhado durante os projetos com 


tecnologias apropriadas, como conversores de alta eficiência. 


2.4.3 MICROCONTROLADORES 


Um microcontrolador pode ser considerado como um computador construído em um único 
chip de material semicondutor. Eles são usados em ampla variedade de aplicações. Eles são acha- 
dos na indústria automotiva, em sistemas de comunicação, de instrumentação eletrônica, em equi- 
pamentos hospitalares, aplicações e equipamentos industriais, aparelhos eletrodomésticos, brin- 
quedos e assim por diante. Os microcontroladores, em geral, são projetados para serem usados em 
aplicações em que eles façam um pequeno número de tarefas no menor custo econômico possível 


(VALDÉS-PÉREZ:; PALLAS-ARENY, 2009). 


2.4.3.1 INTEL 8051 


O 8051 da Intel é um microcontrolador clássico e versátil com um processador Booleano 


com muita capacidade, que suporta instruções para manipulação de bits em aplicações de controle 
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industrial em tempo real. É um sistema microprocessado baseado na arquitetura Harvard, com 
opcionalmente versões von-Neumann (SHIBU, 2009). 

A arquitetura básica do microcontrolador 8051 consiste de uma CPU de 8 bits com capaci- 
dade de processamento de Booleana, 4K de bytes de memória de programa on-chip, 128 bytes de 
memória interna de dados, 128 bytes de memória para registradores especiais, 32 linhas I/O de 


propósito geral, dispositivo UART para transmissão serial etc (SHIBU, 2009). 


2.4.3.2 MICROCHIP PIC 


PIC (Programmable Interface Controller, do inglês) é uma família de microcontroladores 
inventada pela empresa Microchip. Com um conjunto reduzido de instruções, a arquitetura do PIC 
suporta um processamento em 8, 16 e 32 bits. A frequente vertente para 8 bits engloba o PIC10F, 
PICI2F, PIC16F e PIC18F, diferindo na quantidade de memória de programa, performance, com- 
primento de instruções e número de pinos. Ver a Figura 2.34 (SHIBU, 2009). 


Figura 2.34 — O PIC16F84, um dos mais antigos microcontroladores de 8 bits. 


Fonte: Circuits Today (2011). 


Todos os microcontroladores PIC são baseados na arquitetura Harvard, de memória sepa- 
rada para programa e dados. O programa possui uma memória organizada em palavras de 12, 14 e 
16 bits, mas a memória de dados é baseada em registradores de 8 bits. A execução de instruções é 
através de pipelining, um processamento paralelo em que cada instrução é correspondente a um 


ciclo de dois passos, com algumas exceções (VALDÉS-PÉREZ; PALLAS-ARENY, 2009). 
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A família PIC é caracterizada por possuir uma grande variedade de dispositivos I/O. Eles 
têm portas paralelas de 8 bits, timers ou temporizadores, portas seriais síncronas e assíncronas, 
conversores ADC (Analog to Digital Converter, do inglês) e DAC (Digital to Analog Converter, 


do inglês), moduladores de largura de pulso, entre outros. 


2.4.3.3 ATMEL AVR 


AVR 8-bit RISC é o nome de uma popular família de microcontroladores da Atmel, em- 
presa fabricante da área. São de alta performance e baixa potência, operando com tensões entre 1,8 
Ve5,5 Ve executando instruções em um único ciclo de clock. Ainda, são disponíveis em diferentes 


tipos quanto à robustez: tiny AVR, megaAVR — Figura 2.35 — e XMEGA (SHIBU, 2009). 


Figura 2.35 — Integrante da classe megaAVR de Atmel em um projeto de hardware PCB. 


Fonte: Atmel (2017). 


Os microcontroladores AVR seguem o padrão de arquitetura Harvard, memórias e barra- 
mentos separados para programa e dados. Possuem também pipelining simples com antecipação 
de instruções durante o processamento de determinada instrução. 

Considerando todas as suas características vantajosas, os microcontroladores AVR 
foram selecionados para o estudo caso deste trabalho, sendo que um detalhamento sobre eles 


é apresentado na seção 2.5. 
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2.4.3.4 ARM 


O ARM (Advanced Risc Machine, do inglês) é um poderoso processador RISC de 32 bits 
da ARM Holdings. Trata-se de um processador RISC que suporta múltiplos níveis de pipelining 
para a execução de instruções, o que aumenta sua velocidade de processamento. Contém 37 regis- 
tradores com 32 bits cada, sendo que 30 são para propósito geral e 16 são aptos ao modo usuário 
de operação, que é o principal com isolação e proteção do sistema operacional em relação às apli- 
cações de usuário (SHIBU, 2009). 

A arquitetura ARM evoluiu muito desde a primeira versão ARM1 para a ARMI1, a última 
de sua geração. Os processadores ARMI, ARM2, ARM3, ARM 4&5, ARM6, ARM”, ARMS, 
StrongARM, ARMO9, ARMIO e ARMII1 são as famílias de produtos da marca ARM desde sua 


introdução ao mercado. Atualmente, a linha em vigor denomina-se Cortex (SHIBU, 2009). 


2.5 MICROCONTROLADORES AVR 


A ATMEL tem uma ampla gama de microcontroladores AVR (Advanced Virtual Risc, do 
inglês) disponíveis para uso em todos os tipos de dispositivos elétricos, sendo que se deve escolher 
o mais compatível com a tarefa. Por exemplo, torradeiras, refrigeradores e cafeteiras não precisam 
de memória ou portas I/O em excesso, cabendo a aplicação de um pequeno e barato ATtiny13. Já 
para máquinas com visores gráficos ou muitos botões de entrada, um AVR mais robusto seria ne- 


cessário, como o ATmega328 (GRACE, 2016). 


2.5.1 FAMÍLIA AVR DE MICROCONTROLADORES 


* tinyAVR: Menor versão dos microcontroladores AVR de 8 bits. Número limitado de pi- 
nos. Pode conter até 8K bytes de memória FLASH, um tipo de memória não-volátil baseada em 
EEPROM, interna de programa e 512 bytes de SRAM e EEPROM (Electrically Erasable Pro- 


grammable Read-Only Memory, do inglês), uma ROM programável por disparos elétricos. Essa 
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classe de microcontroladores são comuns para aplicações de propósito geral. 

* megaAVR: Microcontroladores AVR de alta performance com multiplicador de 
hardware. Pode conter até 256K bytes de memória FLASH interna de programa, 8K bytes de 
SRAM e 4K bytes de EEPROM. 

* XMEGA: Microcontroladores AVR de alta performance com periféricos avançados como 


sistemas de evento. 


Figura 2.36 — Membros da família AVR de microcontroladores da Atmel. 


ATmega32 


ATmega328 


Ea ATtiny13 


Fonte: Grace (2016). 


A família AVR também engloba controladores orientados a aplicações, projetados em de- 
talhes para situações específicas, como sistemas de iluminação no caso do Lighting AVR, de auto- 
móveis no csao do Automotive AVR, entre outros (SHIBU, 2009). 

Entre os microcontroladores da família ATMEL AVR RISC, os seguintes são muito em- 
pregados: ATtiny13, ATtiny85, ATmega328 e ATmega32, que são sistemas de 8 bits. Os referidos 
possuem, em geral, encapsulamentos DIP (Dual In-Line Package, do inglês), o que facilita sua 
montagem em placas de prototipagem. Esses dispositivos físicos são ilustrados na Figura 2.36 


(GRACE, 2016). 
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2.5.2 ARQUITETURA DE HARDWARE INTERNA 


Na família AVR, que usa a arquitetura Harvard, o programa firmware é armazenado em 
memória FLASH, enquanto registradores e dados são guardados em memória SRAM. Por terem 
arquitetura de instruções RISC, a maioria das instruções do microprocessador são rodadas em um 
único ciclo de clock. Outra característica marcante é a otimização para controle de hardware, o que 
significa que o conjunto de instruções a nível de máquina provê instruções convenientes para per- 
mitir o fácil controle de dispositivos I/O. Instruções de setting, clearing e interrogating para únicos 
bits, em portas paralelas ou registradores, são um exemplo disso (BARNETT et al., 2007). 

Em particular, a AVR 8 CPU contém uma ALU de 8 bits, 32 registradores de 8 bits para 
propósito geral, ponteiro para stack, contador de programa, registrador de instruções, decodificador 
de instruções e registrador de status e controle. A Figura 2.37 é um diagrama de blocos sobre a 


arquitetura do microcontrolador AVR ATmegas. 
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Figura 2.37 — Arquitetura do microcontrolador AVR ATmega8, com destaque para a CPU. 
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Fonte: Shibu (2009). 


A arquitetura da megaA VR suporta múltiplas portas bidirecionais. As portas podem ser 
configuradas como de entrada ou de saída. Cada uma porta contém um grupo de pinos de porta, 
com até 8 pinos. As portas I/O têm diodos de proteção para alimentação e terra, além de serem 
levadas a nível lógico 1 por resistores de pull-up internos. A família AVR também tem um dispo- 
sitivo USART embutido, para comunicação de dados síncrona ou assíncrona, o que é feito por 


portas e registradores específicos (SHIBU, 2009). 
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2.5.3 PROGRAMAÇÃO AVR EM LINGUAGEM C 


Através do AVR ou Atmel Studio, um microprocessador AVR pode ser programado em 
linguagem Assembly, C ou C++. A linguagem C tem a vantagem da conveniência, mas o Assembly 
é rápido e eficiente. De modo otimizado, é possível escrever um programa em C com inserção de 


Assembly no mesmo, técnica denominada inlining (GRACE, 2016). 


Figura 2.38 — Código em C para AVR para uma subrotina de pausa em execução. 


*include <avr/io.h> 


*define SWITCH PINB 
ádefine SWITCH DDR DDRB 
ádefine LEDS PORTD 


gdefine LEDS DDR DDRD 
voiddelay ms (int t); 


int main(void) 


1 
SWITCH DDR = 0x00; // Set data direction register to input 
LEDS DDR = O0xff; // Set data direction register to output 
if (SWITCH &0b01) delay ms(2000);  //Wait if pinbO is high 
LEDS = 0xff; // Light LEDS 
k 
(mu a a e e e e mm mm 
void delay ms (int t) // tis the & of msec to delay for. 
À 
for (int j=0;j<t;j++) 
for (short i=0;i<54;i+);  // This loop is about 1 ms 
return; 
k 
[mm me me, a a q q o e e e e e e e e e e e e e e 


Fonte: Grace (2016). 


Pela maior parte, em comparação o €, como na Figura 2.38, é mais fácil de programar, mas 
não executa rápido como o Assembly e o código tende a ter um tamanho maior em memória. Já o 


C++, apesar de ter um nível de abstração maior, perde em eficiência para a linguagem C. 
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2.6 HARDWARE NO CONTROLE POR INTERFACE GRÁFICA 


Faz-se relevante o conhecimento das características teóricas de um sistema de hardware o 
qual é controlado por uma interface gráfica. Isso devido a uma interface ser programada para inte- 
ragir com componentes de hardware, além do software internalizado no microcontrolador do sis- 
tema embarcado. Princípios de números binários, registradores digitais, sistemas microprocessados 
e barramentos de comunicação esclarecem questões a respeito do funcionamento prático de uma 
interface gráfica para sistema eletrônico, como em casos de problemas de manutenção. 

No capítulo IV deste trabalho, será abordado o desenvolvimento de interfaces gráficas em 
Linux PC em específico, o que contudo é dificultado na ausência de conhecimentos do hardware. 
A programação de transferências via USB supõe noções de um padrão de barramento digital espe- 
cífico, enquanto da mesma forma a criação de um firmware para um microcontrolador AVR supõe 
noções da organização eletrônica deste. 

O sistema físico completo do trabalho é ilustrado no diagrama da Figura 2.39. Os sensores 
e os atuadores são mecanismos digitais que se relacionam com o sistema embarcado, que por sua 
vez interage com o computador pessoal o qual executa uma interface gráfica em Linux. Dentre os 
sensores, pode-se citar, como exemplos, termômetros e velocímetros, enquanto entre os atuadores 


pode-se citar motores e aquecedores. 


Figura 2.39 — Diagrama de um sistema físico com PC — interface gráfica — e sistema embarcado. 
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Computador 
Pessoal 


Fonte: Jesner (2016). 
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3 SOFTWARES NA INTERAÇÃO HOMEM-MÁQUINA 


Neste capítulo, serão tratados princípios sobre software, conceitos sobre o sistema operaci- 
onal GNU Linux e distribuições, interfaces de usuário, bibliotecas gráficas de desenvolvimento e, 


finalmente, gerenciamento USB no Linux para microcontroladores AVR. 


3.1 PRINCÍPIOS DE SOFTWARE 


Especificamente, nesta seção serão apresentadas definições de software, possibilidades de 


firmware e, por fim, a estrutura básica de um sistema operacional genérico. 


3.1.1 DEFINIÇÃO GERAL DE SOFTWARE 


Em adição ao componente de hardware, um sistema microprocessado ou computador tam- 
bém requere o software. Essa parte consiste de programas que dizem ao computador o que fazer. 
Isso é relevante por que, para realizar trabalho útil, o hardware precisa executar determinada ins- 
truções a partir de um programa. 

Como definição, qualquer programa virtual de computador é um software. Por sua vez, o 
programa é um conjunto de instruções que o microprocessador pode executar. Na memória de pro- 
grama, que pode ser de diversas naturezas, o código é armazenado em forma de números binários, 
chamados instruções de máquina. Apesar disso, outras memórias são passíveis de manipulação por 
qualquer software, como a memória RAM (HUANG, 2005). 

Pode-se classificar os softwares, geralmente, em de sistema e de aplicação. Quando se trata 
de um software de sistema, refere-se a: manipulação de arquivos; carregamento de arquivos; co- 
mandos a partir de mouse e teclado; etc. Já os softwares de aplicação costumam ser criados visando 
a sua usabilidade em relação a um leigo: editores de texto, jogos virtuais, navegadores, entre outros 


(ENGLANDER, 2009). 
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3.1.2 FIRMWARE E PARTICULARIDADES 


A definição de firmware é de uma montagem composta de uma unidade de hardware e de 
um programa integrado para formar uma entidade funcional cuja configuração não pode ser alte- 
rada durante a execução do programa. Um programa de computador é armazenado em uma unidade 
de hardware como um circuito integrado com especificações fixas, de modo a satisfazer um reque- 


rimento operacional (SUMMERS, 2011). 


Figura 3.1 — O conceito de firmware, na interpretação de software para embarcados. 


4 Firmware Update 


Do you want to update your router 
( firmware now? 


| Update Now 


Fonte: Setup Router (2007). 


Outra definição de firmware é a de um programa embarcado que facilita o hardware asso- 
ciado a realizar suas funções de hardware requeridas. A relação existente entre hardware e fir- 
mware é interdependente, sendo que os testes de qualificação do hardware requereriam que o fir- 
mware estivesse armazenado no dispositivo físico. Representação na Figura 3.1. 

Relativamente, um firmware pode ser identificado com componentes inerentes tanto a 
hardware quanto a software. Se um código executável é um firmware, então ele se assimila a um 
software. Quando o firmware é uma configuração de hardware, já se tem similaridade do mesmo 
com os métodos para desenvolver um projeto de hardware com integrados de alta velocidade 


(SUMMERS, 2011). 
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3.1.3 SISTEMAS OPERACIONAIS 


Os softwares de sistema que controlam os recursos do computador são coletivamente co- 
nhecidos como sistema operacional. Diferem de aplicações como Firefox ou Microsoft Word, pois 
não servem especificamente para certas tarefas de usuário. Exemplos de sistemas operacionais são 
o Microsoft Windows e o GNU Linux. Outros incluem o Mac OS X, Unix e derivados (ENGLAN- 
DER, 2009). 

O sistema operacional é uma parte essencial de um sistema computacional. Assim como o 
hardware, o mesmo é constituído de vários componentes. Um diagrama simplificado de um sis- 
tema operacional é mostrado na Figura 3.2. O elemento mais claro é a interface de usuário que 


permite a execução de programas, entrada de comandos e manejo de arquivos. 


Figura 3.2 — Diagrama de um sistema operacional básico de computador pessoal. 
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Fonte: Englander (2009). 
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A API (Application Program Interface, do inglês) de um sistema operacional atua como 
uma interface para aplicações e utilitários para acessar os serviços internos do mesmo. Isso inclui 
serviços de arquivo, de entrada-saída, de comunicação de dados, de interface de usuário, de execu- 
ção de programas etc. Muitos dos serviços internos são providos pelo módulo kernel, que contém 
as funções mais importantes do sistema operacional. O núcleo ou kernel é a parte que essencial- 
mente conecta hardware e software, encarregando-se de manipular a memória alocando espaço 
para programas, estimar o tempo da execução de cada aplicação e controlar recursos providos de 
outros módulos, além de fornecer segurança (ENGLANDER, 2009). 

Entre os demais componentes de um sistema operacional básico, tem-se o sistema de ma- 
nejo de arquivos, que organiza espaço secundário de armazenamento. Há ainda drivers I/O, que 
servem justamente para solicitar e guardar informações no sistema de arquivos. Por fim, há o mó- 


dulo de rede, que se encarrega das comunicações entre o computador e redes, como a Internet. 


3.2 SISTEMA OPERACIONAL UNIX E DERIVADOS 


Na seção a ser explicada, será tratado sobre o Unix e o Linux, de propriedades que foram 
aplicadas neste trabalho, e suas características históricas e funcionais. Ainda, será realizada uma 
abordagem sobre a distribuição Ubuntu, popular atualmente e por isso empregada nos programas 


criados para o trabalho, além de sua base Debian que originou muitos de seus princípios. 


3.2.1 HISTÓRIA DO UNIX 


O Unix é um sistema operacional multiusuário desenvolvido por Dennis Ritchie e Ken Tho- 
mpson na AT&T Bell Labs. O sistema Unix começou como um pequeno projeto de um sistema 
operacional para rodar um jogo disponível para computador PDP-7. Entretanto, o Unix evoluiu nos 
15 anos seguintes para um software significativo de propósito-geral, do ponto de vista comercial. 
Baseado em um antigo projeto da Bell Labs denominado Multics, Ken Thompson nomeou como 
UNICS (Uniplexed Information and Computing Service, do inglês) o sistema operacional que de- 


pois viria a ser conhecido como Unix (JAEGER, 2008). 
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O criador Dennis Ritchie reescreveu o Unix em sua nova linguagem de programação C que 
fez o Unix apto a ser o primeiro sistema operacional portável. Isso incentivou a criação de uma 
comunidade Unix, pois qualquer hardware estaria capacitado a executar o sistema. Foi feita então 
uma API, interface para programação de aplicativos, em C para programadores que de alguma 
forma escrevessem aplicações para o Unix, de forma independente de instruções em Assembly. No 
final, o Unix tornou-se simplificado em relação ao Multics, apesar de muitos dos princípios daquele 
terem sido baseados neste: sistema hierárquico de arquivos, memória virtual, senhas criptografa- 


das, entre outros (JAEGER, 2008). 


3.2.2 GNU LINUX E DISTRIBUIÇÕES 


O Linux foi criado em 1991, com seus primórdios datando aos tempos da computação mo- 
derna em meados de 1970. Seu criador é o finlandês Linus Torvalds, que resolveu instalar no com- 
putador uma versão do Unix denominada Minix, do professor Andrew Tanembaum, em vez de um 
sistema DOS (Disk Operating System, do inglês). Isso o incentivou a criar um sistema Minix único, 
ideia a partir da qual o sistema operacional Linux 0.01, da Figura 3.3, surgiu depois de metade um 
ano. Uma das ações em relação ao Linux inicial que o fez tornar-se popular foi o seu compartilha- 
mento público (THOMAS, 2006). 

Na época em que Linus lançou o sistema Linux, um outro projeto, chamado GNU (GNU is 
Not Unix, do inglês), de Richard Stallman, existia. Essa equipe de projetos também pretendia criar 
um sistema operacional inspirado no Unix, evitando e corrigindo problemas do mesmo do ponto 
de vista técnico e de licenças. Os softwares GNU eram distribuídos gratuitamente a desenvolvedo- 
res, com o compartilhamento do Linux, nesse tempo, como os modelos GNU (THOMAS, 2006). 

Nos anos 1980, o mundo tornava-se mais corporativo, pois o advento do PC Desktop influ- 
enciou a concepção de software proprietário e secreto. O entusiasta Richard Stallman então fun- 
dava a companhia GNU ao sair de seu emprego no Massachusetts Institute of Technology. Apesar 
de não haver uma união oficial entre os projetos GNU e Linux, a adoção por Linus Torvalds de 
ferramentas gratuitas GNU introduziu o conceito atual de sistema GNU Linux, o qual tem como 


fundamento a aplicação do kernel Linux com aplicações GNU (THOMAS, 2006). 
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Figura 3.3 — Acesso terminal da primeira versão do Linux, a número 0.01. 
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Fonte: Natanael (2014). 


Todas as partes dos softwares GNU eram disponibilizadas para download grátis, ou seja, 
livres de custos. A montagem de um sistema operacional, porém, não era conhecida por todos, o 
que fez com surgissem novos sistemas operacionais baseados no GNU Linux: as chamadas distri- 
buições ou, de modo reduzido, distros. Entre as companhias e grupos de entusiastas que facilitavam 
a instalação do núcleo Linux em um disco rígido estavam: Red Hat, SUSE, Debian, Slackware, 


entre outros (THOMAS, 2006). 


3.2.3 SISTEMA OPERACIONAL DEBIAN 


O Debian é uma distribuição Linux independente e dirigido por uma comunidade. Trata-se 
da distribuição que mais possui derivados atualmente, seja diretamente ou indiretamente. A filoso- 
fia, manutenção e comunidade do sistema inspira a dedicação de muitos desenvolvedores, usuários 
e administradores de sistemas, o que torna o Debian Linux especial em termos de destaque entre as 
distribuições Linux atuais (CASTRO, 2016). 

Como um dos mais antigos derivados do GNU Linux, o Debian foi inventado por Jan Mur- 


dock, estudante da Purdue University. Durante seu desenvolvimento, houve a publicação do The 
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Debian Manifesto, Debian Social Contract, entre outras instruções que diferenciava a filosofia do 
Debian Linux em relação aos demais sistemas. Entre os pontos principais dela, pode-se enumerar 


os listados a seguir (CASTRO, 2016). 


. O Debian permanecerá 100% gratuito. 

. A comunidade de software livre será retribuída. 

. Não serão escondidos problemas quanto ao projeto. 

. As prioridades são os usuários e o chamado software livre. 


. Trabalhos que não atenderem os padrões de software livres são aceitáveis. 


Ademais, o Debian é essencialmente uma distribuição de propósito geral com única versão 
para todos os propósitos, o que significa mesma imagem para Desktop e Server, entre outros. Con- 
tudo, tal distribuição não é particularmente amigável e perde nesse quesito para o Ubuntu ou Fe- 
dora. Sua estabilidade é garantida conforme a versão escolhida para esse objetivo e, entre suas 


versões mais recentes, destaca-se o Debian 8, como na Figura 3.4 (CASTRO, 2016). 


Figura 3.4 —- O Debian 8, com características user-friendly na instalação e ambiente. 


Debian GNU/Linux installer boot menu 


Install 

Graphical install 

Advanced options 

Help 

Install with speech synthesis 


Press ENTER to boot or TAB to edit a menu entry 


Fonte: Servidor Debian (2017). 
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3.2.4 UBUNTU LINUX NA ATUALIDADE 


O Ubuntu é uma distribuição relativamente nova do Linux, baseada e ainda muito próxima 
da distribuição Debian, como muitas versões atuais do sistema Linux. Como ideia de projeto, o 
Debian existe há quase tanto tempo quanto o núcleo Linux conforme o espírito e filosofia deste, a 
qual prega que softwares devem ser compartilhados e disponibilizados para qualquer um que o 
queira — licenciamento de código aberto — (THOMAS, 2006). 

O objetivo do sistema operacional Ubuntu é fornecer a qualquer indivíduo no mundo o 
acesso a uma versão Linux de fácil uso, independentemente de localização geográfica ou habilida- 
des físicas. O Ubuntu suporta um grande número de linguagens e por isso pode ser usado em vari- 
ados países, incluindo ainda diversas ferramentas de acessibilidade. O nome do software, Ubuntu, 


tem origem africana e expressa humanidade em relação aos demais. Ver a Figura 3.5. 


Figura 3.5 — O ambiente Unity do sistema operacional Ubuntu Linux. 


Ubuntu Desktop ty EB = o) ozorm 


Fonte: Blum; Bresnaham (2015). 
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O Ubuntu é voltado primariamente para usuários Desktop comuns, apesar de haver varia- 
ções com certas adaptações a fim de execução em ambiente de servidor. Construído para ser um 
sistema user-friendly ou amigável ao usuário, o sistema Ubuntu Linux possui uma diversidade de 
programas de um sistema operacional moderno, como um editor gráfico, um navegador de Internet 
e um aplicativo de e-mails. Atualizações e instalações do próprio sistema ou de aplicações são 
realizadas com pouco uso do mouse ou da linha de comando, com o terminal sendo universal para 


controles deste o primeiro Linux (THOMAS, 2006). 


3.3 INTERFACES GRÁFICAS USANDO LINUX 


Os serviços de usuário constituem um propósito fundamental para a existência de um sis- 
tema operacional e uma interface de usuário é essencial para o acesso a esses serviços. Não para 
menos, alguns sistemas elegem a visão da interface de usuário, até mesmo de muitos serviços de 
usuário, como externamente ao escopo do sistema operacional. Programas como esses são tratados 


como um núcleo que por si interfaceia com o sistema inteiro (ENGLANDER, 2009). 


3.3.1 CONCEPÇÃO DE INTERFACE DE USUÁRIO 


O objetivo primário da interface de usuário é fazer com que as atividades do sistema com- 
putacional sejam acessíveis para o usuário, assim realizando seu trabalho conveniente e eficiente- 
mente. Nos sistemas modernos, um propósito secundário da concepção original é aplicado: o sis- 
tema operacional provê serviços de interface de usuário para aplicações dos quais derivam progra- 
mas cujas próprias interfaces de usuários operam do mesmo jeito. Isso simplifica o uso em dife- 
rentes aplicações e a curva de aprendizagem do usuário para novos programas (ENGLANDER, 
2009). 

Uma interface devidamente projetada é capaz de melhorar a experiência do usuário do sis- 
tema e fazer o uso do sistema computacional satisfatório. Trata-se de um benefício aos usuários 
que é maximizado para fins específicos. O valor potencial de um software como um todo pode ser 
prejudicado se a interface de usuário não for suficientemente acessível. Para o usuário e seus pro- 


gramas, o sistema operacional possui serviços de interface por: 
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º Uma interface de comando de algum tipo que aceite comandos de alguma 
maneira diretamente a partir da interface de usuário. Mais comumente, a interface é grá- 
fica, GUI (Graphical User Interface, do inglês) ou de linha de comandos, CLI (Command 
Line Interface, do inglês). Representação da CLI na Figura 3.6. 

º Uma linguagem de comandos que aceite e execute grupos organizados de 
comandos como uma forma de programa. A maioria das linguagens de comandos são ca- 
pacitadas para criação de escopos, condicionais e laços, além de entradas requisitadas ao 
usuário e passagem de argumentos. São também referidas como linguagens de scripting. 

º Uma interface que aceite e efetue solicitações aos serviços do sistema ope- 


racional direto dos programas do usuário, ou seja, uma API. 


Figura 3.6 — Pequeno programa criado em linguagem de comandos, no Ubuntu Linux. 


zlaiOZLai: - k 
NT -/chess 


zlaiQgzLai:-S i 


Fonte: Hello ACM (2017). 


Finalmente, os sistemas modernos expandem o conceito de serviços I/O para prover bibli- 
otecas de rotinas especializadas que podem ser usadas por programas para criar gráficos, controlar 
o mouse, gerar e manipular janelas de usuário, criar e controlar menus, entre outras funções sofis- 


ticadas (ENGLANDER, 2009). 
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3.3.2 INTERFACES GRÁFICAS DE USUÁRIO 


Há dois tipos de interface de usuário para uso comum. Uma dessas é a interface de linha de 
comando ou CLI, que é vista em uma ampla variedade de sistemas operacionais, incluindo o Com- 
mand Prompt do Windows. Apesar de essa ser a mais comum das interfaces do ponto de vista 
histórico, a interface gráfica de usuário ou GUI suplantou a CLI para a maioria das atividades 
rotineiras. As GUIs são vistas no Macintosh da Apple, em PCs de base Windows, estações de tra- 
balho da Sun, além da maioria de sistemas Linux do tipo Desktop. Também há telefones móveis e 
outros aparelhos que fazem uso da GUI (ENGLANDER, 2009). 

Sistemas janelados, como na Figura 3.7, de diferentes fabricantes incorporam diferentes 
aparências, porém compartilham elementos similares. Normalmente, uma interface gráfica consiste 
de uma ou mais screens — telas — ou desktops — áreas de trabalho — com cada uma contendo uma 
ou mais janelas. Uma janela é uma porção da tela a qual é alocada para o uso em um programa 
particular, processo ou documento. Janelas contêm gadgets ou widgets para redimensionar os grá- 
ficos, para movimentar as janelas em torno da tela, para rolar dados e imagens dentro da janela, e, 


para movimentar janelas pela frente e por trás das demais. 


Figura 3.7 — Interface gráfica de usuário no ambiente operacional Windows. 


Fa 
ad Customer o || tell ê 


First Name 
Last Name 
Email 
Phone 


Gender Male Female 


OK Cancel 


O 


Fonte: MSDN Blogs (2010). 
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Por fim, é útil considerar a exibição de objetos dentro de uma janela, como imagens em 
uma aplicação de processamento de fotografias ou texto formatado em um processador de palavras, 
ou ainda, uma página em um navegador Web. As aplicações usam as facilidades da API do sistema 
operacional para produzir visualizações reais. Em contrapartida, o sistema operacional também cria 
seu próprio desktop, um visor global, usando seu próprio software e controladores gráficos (EN- 


GLANDER, 2009). 


3.3.3 PROJETO GTK+ 


Um dos aspectos mais importantes de uma aplicação é a interface que é provida para inte- 
ragir com o usuário. Na sociedade atual, espera-se que interfaces sejam sempre gráficas, o que abre 
espaço para um conjunto específico de serviços gráficos. Muitos escolhem a rica e multiplataforma 
biblioteca denominada GTK+ (GIMP Toolkit Plus, do inglês). O GTK+ foi originalmente projetado 
para um editor gráfico raster chamado GIMP (GNU Image Manipulation Program, do inglês). 
Três indivíduos, Peter Mattis, Spencer Kimball e Josh MacDonald criaram o GTK+ em 1997 en- 
quanto trabalhavam na Universidade da Califórnia, Berkeley (KRAUSE, 2007). 

Licenciada sob a licença LGPL (Lesser General Public License, do inglês), que permite 
ambos os usos por softwares gratuitos e proprietários, o GTK+ adotou o estilo gráfico padrão do 
GNOME e XFCE, dois dos mais populares ambientes Linux de área de trabalho. Apesar de ser 
originalmente usado no sistema operacional Linux, a plataforma GTK+ foi expandida para suportar 
outros ambientes Unix-like, como Microsoft Windows e Mac OS X. Ver a Figura 3.8. 

Em princípio foi lançada a versão original GTK+ 1, que precisou ser dramaticamente mo- 
dificada para incluir novos artifícios com preocupação por parte dos desenvolvedores em quebrar 
a compatibilidade da API. A segunda versão estável, GTK+ 2, introduziu novidades como o motor 
gráfico para redimensionamento de fontes Pango e suporte melhorado para acessibilidade. Na 
GTK+ 3, versão corrente da biblioteca, manteve-se a compatibilidade com as versões anteriores, 


além de melhoras no caráter multiplataforma (KRAUSE, 2007). 
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Figura 3.8 — Tipos de widgets GTK+: botões, barras, formulários etc. 


[m| Gtk2 Theme Selector X 
Theme Preview 
Metal -*! | | Common widgets Text area | About | 
Mist Pr v check button 1 File Edit Help 
| check button 2 ao | a 
a button 
litem 1 p= 
Fem = 
(Use theme default font — 15 
(e Use custom font a FZ — [> 
Arial | 10 | 
frame Text w Number E 
Hide preview << (+: radio 1 » Parent 1 65 | 
7 Mig should restart your programs ” radio 2 Parent2 66 E 
for this change to take effect. ( radio 3 E 
E FS 
Pneset | Hesncel) OK | | | 


Fonte: GTK+ Windows SourceForge (2007). 


3.3.4 BIBLIOTECA C++ WXWIDGETS 


O wxWidgets, com representação na Figura 3.9, é um framework para programadores es- 
creverem aplicações desktop ou móveis com interfaces gráficas de usuário ou GUIs, padronizando 
o comportamento padrão dos softwares desenvolvidos. A biblioteca wx Widgets contêm um grande 
número de classes e métodos para o programador usar e configurar. Aplicações típicas mostram 
janelas contendo controles padrões, possivelmente desenhando imagens e gráficos especializados 
e respondendo às entradas do mouse, teclado ou outras fontes. Assim, o wxWidgets torna fácil, 
relativamente, para um programador escrever uma aplicação capaz de fazer tudo que outra aplica- 


ção moderna possa fazer (SMART; CSOMOR, 2006). 
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Figura 3.9 — Desenvolvimento com wxWidgets de uma interface gráfica para Linux. 
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Fonte: Bolia (2006). 


Uma área em que o wx Widgets difere de vários outros frameworks, como o MFC (Microsoft 
Foundation Classes, do inglês), é a sua natureza multiplataforma. O wxWidgets possui uma inter- 
face de programação de aplicativos — API — que é aproximadamente a mesma em todos os sistemas 
suportados, o que significa que os programas quase não precisam ser reescritos em uma mudança 
de sistema operacional. Ainda, o wxWidgets possui um native look and feel, pois usa os widgets 
nativos do sistema operacional sempre que possível, deixando suas próprias ferramentas para ou- 
tros casos. Não só a aparência, então, identifica-se como nativa, mas também o próprio funciona- 
mento do programa, sendo não apenas uma simulação de determinado ambiente. 

A linguagem da biblioteca wx Widgets é sobretudo a C++. Enquanto para aplicações basea- 
dos em Web outras linguagem, como Java, são relevantes, essa não é sempre a melhor opção para 
ambientes Desktop. Em geral, aplicações baseados em C++ usando wxWidgets são mais rápidas, 
tendo look and feel nativos, além de mais fáceis de instalar por não terem dependência, por exem- 
plo, da máquina virtual do Java. A linguagem C++ também permite um maior acesso à funcionali- 
dades de baixo nível e é mais fácil de integrar com códigos em C já existentes. Pode-se explicitar 
que o wxWidgets, portanto, permite a entrega de aplicações de alta performance e nativas ao sis- 


tema, o que é esperado pelo usuário (SMART; CSOMOR, 2006). 
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O projeto vx Widgets foi iniciado em 1992 quando Julian Smart estava trabalhando na Uni- 
versidade de Edinburgh em uma ferramenta de diagramas chamada Hardy. Ele não quis criar de- 
pendências com a empresa Sun, por exemplo, e então decidiu fazer sua própria biblioteca multipla- 
taforma, o que resultou na escolha do wxWidgets 1.0 pela universidade. Assim, o wxWidgets tem 


o caráter de código aberto ou open-source (SMART; CSOMOR, 2006). 


3.4 PROGRAMAÇÃO EM C PARA FIRMWARE AVR 


Escrever um programa em linguagem C é, em certo sentido, construir uma casa de tijolos: 
uma fundação é deixada, areia e cimento são misturados para fazer tijolos, esses tijolos criados são 
organizados em linhas para gerar cursos de blocos, e, por fim, os cursos de blocos são empilhados 
para montar uma edificação. Em um programa embarcado em C, conjuntos de instruções são colo- 
cados juntos para formar funções. Estas, então, são tratadas como operações de alto nível, que são 
combinadas para formar um programa final a ser executado por um sistema eletrônico micropro- 


cessado (BARNETT et al., 2007). 


3.4.1 ESTRUTURA BÁSICA DE UM CÓDIGO AVR 


O ambiente de desenvolvimento integrado Atmel Studio 6.2 no sistema operacional Win- 
dows, disponibilizado gratuitamente no site da Atmel, fabricante dos microcontroladores AVR, é 
adequado a processos de compilação e depuração de códigos embarcados em geral. Escolhendo o 
microcontrolador AVR do tipo ATmega328P, tem-se um editor de códigos no IDE (Integrated 


Development Environment, do inglês) Atmel Studio, como na Figura 3.10. 
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Figura 3.10 — Código básico em linguagem C para microcontroladores AVR usando o Atmel Studio. 


finclude <avr/io.h> 


=jint main(void) 


t 
for(;;) //Execução eterna, impedindo o desligamento elétrico do microcontrolador. 
t 
3 |fDeclaração vazia (empty statement), que não tem nenhum efeito. 
k 
return 0; 
k 


Fonte: Jesner (2017). 


Um código C simples para AVRs deve incluir como arquivo de cabeçalho aditivos para 
realizar certas funcionalidades. Na Figura 3.10, esse arquivo é o io.h da pasta avr, que capacita 
o microcontrolador a manipular suas portas de entrada-saída. Além dele, há outras bibliotecas pos- 
síveis, como as padrões da linguagem C desde a convenção ANSI (American National Standards 
Institute, do inglês), que são: stdio.h, ctype.h, string.h, math.h, time.h, assert.h, 
stdarg.h, setjmp.h, signal.h, float.h, limits.hestdlib.h. 

O main é a função de entrada de qualquer projeto em linguagem C. Seu retorno é inteiro e 
pode ser O ou 1, respectivamente, para sinalizar execução com sucesso e com falha. Em sua lista 
de parâmetros, usa-se o tipo de dado void para indicar a ausência de parâmetros, o que é natural 
em um sistema eletrônico embarcado. 

Verifica-se que a construção for é um laço que engloba o programa todo, o que indica a 
impossibilidade do return final ser executado, pois o loop é infinito. Isso é feito para não haver 
um desligamento elétrico do chip do microcontrolador, pois isso seria um reinício de circuitos, 
contadores, entre outros detalhes indesejados. Dentro do laço, uma declaração que não faz nada é 
inserida para objetivos de exemplificação somente, sendo que na prática esse seria o local onde 


determinado código funcionaria (BARNETT et al., 2007). 
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3.4.2 CONFIGURAÇÃO DE REGISTRADORES 


Um microcontrolador AVR possui diversos registradores de CPU, que possibilitam para o 
programador a realização de cálculos, movimentação de dados, acesso à memória e a dispositivos 
IO, além de tomada de decisões. No caso do AVR ATmega328P, há três portas de I/O: portb, 
portc e portd. À direção de cada porta é determinada pelo seu DDR — DDRB, DDRC e DDRD — ou 
registrador de direção de dados. Se um bit do registrador DDR é definido como “0”, o pino corres- 
pondente na porta é configurado como pino de entrada, enquanto que no caso do bit como “1º tem- 
se que o pino é definido como saída. Vale frisar que tanto os bits do valor quanto os bits de direção 


da porta são tratados individualmente (GRACE, 2016). 


Figura 3.11 — Um projeto no Atmel Studio para ATmega328P a fim de piscar um LED no pino PBS. 


tidefine F CPU 16000000UL //Frequência para a biblioteca 'deyal.h'. 


include <avr/io.h> //Biblioteca para os registradores do MCU AVR. 
include <util/delay.h> //Biblioteca para funções de espera/delay. 


“int main(void) 


t 
DDRB = 0b00100000; //Define o pino PB5 como saída e os demais como entradas. 
for(;;) 
t 
PORTB “= (1 << PB5); //Inverte o estado em que estiver o pino PBS. 
“delay ms(1000); //Pausa a execução do código inteiro por um segundo. 
k 
k 


Fonte: Jesner (2017). 


Na Figura 3.11, é apresentado um código firmware para fazer piscar um LED (Light Emit- 
ting Diode — no pino PB5 da porta rotulada como “B”. Seguindo a estrutura básica AVR, inclui-se 
adicionalmente um arquivo delay .h da pasta util a fim de criar a função delay ms para pau- 
sar por um certo tempo o processamento do código. Isso, porém, requere uma especificação para a 


frequência de operação do clock interno, definida no topo do código como 16 MHz. 
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Como os pinos PB são contados de PBO a PB7, o registrador de direção DDRB é um byte, 
composto de 8 bits. Da direita para a esquerda, a casa binária 5 é modificada por linha de código 
para “1º, especificando PB5 como saída, enquanto os demais são definidos como “0” para serem 
entradas. Depois, uma máscara binária é aplicada no registrador PORTB para interverter o valor do 
pino PB5, seja qual for ele no momento, com isso feito dentro do eterno laço for do código. Isso, 
aliado com a função de delay, faz um LED em PBS piscar a cada um segundo. É interessante notar 
que os registradores PORT — PORTB, PORTC e PORTD — têm 8 bits cada e armazenam o valor, em 


certo instante, de qualquer porta I/O. Ver a Figura 3.12. 


Figura 3.12 — Pinagem dos microcontroladores AVR ATmega328 e ATmega328P. 


(PCINT14/RESET) PC6 Cl] 1 
(PCINT16/RXD) PDO [| 2 
(PCINT17/TXD) PD1 C]3 
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28 [1 PC5 (ADC5/SCL/PCINT13) 
27 [1 PC4 (ADC4/SDA/PCINT12) 
26 [1 PC3 (ADC3/PCINT1 1) 
25 [1 PC2 (ADC2/PCINT1O) 
(PCINT19/0C2B/NT1) PD3 [| 5 24 [1 PC1 (ADC1/PCINT9) 
(PCINT20/XCK/TO) PD4 [] 6 23 [1 PCO (ADCO/PCINT8) 
VCCC]|7 22 [1 GND 
GND [| 8 O AREF 
(PCINT6/XTAL1/TOSC1) PBS [| 9 20 DI AVCC 
(PCINTZ/XTAL2/TOSC2) PB7 [1] 10 19 1 PB5 (SCK/PCINTS) 
(PCINT21/0COB/T1) PDS O 11 18 [1 PB4 (MISO/PCINT4) 
(PCINT22/0COA/AINO) PD6 [1] 12 17 [1 PB3 (MOSVOC2A/PCINT3) 
(PCINT23/AIN1) PD7 0] 16 [1 PB2 (5S/0C1B/PCINT2) 
(PCINTO/CLKO/CP1) PBO [1] 14 15 [1 PB1 (OC1A/PCINT1) 


Fonte: Grace (2016). 


3.4.3 COMUNICAÇÃO DIGITAL USART 


No tocante ao sistema de transferência USART, os microcontroladores AVR têm três re- 
gistradores de estado e de controle. No registrador UCSROA as informações são de estado, majori- 
tariamente. Por sua vez, os registradores UCSROB e UCSROC contêm todo detalhe em respeito às 
configurações do USART (TUUPOLA, 2011). 

A biblioteca AVR provê macros de pré-processador para cálculos de transmissão, no caso 
em USART. Ela requere, porém, a definição das constantes F CPU e BAUD, que nessa ordem são a 
frequência de clock e a taxa de transferência denominada Baud Rate. Após a inclusão do arquivo 
de cabeçalho setbaud do diretório util, habilita-se: UBRRL VALUE e, também, UBRRH VALUE. 


Estes são aplicados para definir a velocidade do USART. 


94 


SOFTWARES NA INTERAÇÃO HOMEM-MÁQUINA 


Figura 3.13 — Código para AVR sobre transmissão e recepção de caracteres por mecanismos USART. 


define F CPU 16000000UL //Definição da frequência de clock do microcontrolador. 
&define BAUD 9600  //Definição da Baud Rate da comunicação serial. 


&include <util/setbaud.h> 
include <util/delay.h> 


Flint main(void) 
! 
UBRROH = UBRRH VALUE;  //Configuração da velocidade USART definida por 'BAUD'. 
UBRROL = UBRRL VALUE; !!Configuração da velocidade USART definida por 'BAUD'. 


UCSROA = abBoloaaaa; //Configuração do registrador de estado USART. 
UCSROB = 0b00011000; /!Configuração do registrador de controle USART. 
UCSROC = 0bB0000110; //Configuração do registrador de controle USART. 


for(55) 
t 
unsigned char handle uart; 
loop until bit is set(UCSROA, RXCG); 
handle uart = UDRO; 
switch(handle uart) 
í 
=] case *x': 
í 
loop until bit is set(UCSROA, UDREO); 
UDRO = "A"; 
loop until bit is set(UCSROA, UDREG); 
UDRO = "An"; 
break; 
k 
[| case 'y': 
í 
loop until bit is set(UCSROA, UDREG); 
UDRO = 'B'; 
loop until bit is set(UCSROA, UDREG); 
UDRO = "An"; 
break; 
k 
case 'z': 


t 


à 


loop until bit is set(UCSROA, UDREO); 
UDRO = 'C'; 
loop until bit is set(UCSROA, UDREG); 
UDRO = "An"; 
break; 

k 

=] default: 

í 
loop until bit is set(UCSROA, UDREG); 
UDRO = 'N'; 
loop until bit is set(UCSROA, UDREO); 
UDRO = '"An'; 
break; 


k 


“delay ms(500); 


Fonte: Jesner (2017). 
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Para transmitir um dado por USART, há o registrador de dados denominado UDRO. Antes, 
porém, precisa-se ter certeza de que o mecanismo US ART está pronto para transmitir novos dados. 
Por isso, espera-se até o valor verdadeiro ser detectável no registrador de dados vazios, UDREO. 
Esse procedimento é realizado em cada bloco case da construção switch, na Figura 3.13. 

Para receber um dado pelo dispositivo USART, porém, faz-se uma única vez a leitura ou 
avaliação do valor, em linguagem C, do registrador chamado UDRO. Para isso ser efetivo, é impor- 
tante verificar anteriormente pela recepção completa em RxCO, o que é indicado por valor lógico 
verdadeiro. Na Figura 3.13, uma variável chamada handle uart é criada para o procedimento 
de recepção de um caractere por USART (TUUPOLA, 2011). 

Por fim, se o código da Figura 3.13 fosse executado com conversão USART-USB em PC, 
como seria no caso de uma placa Arduino Uno, o funcionamento seria da seguinte forma: o usuário 
insere, em um programa terminal no PC, um caractere por vez e pressiona Enter; se alguma vez o 
caractere for 'x”, 'y” ou *z”, o sistema embarcado responde, pelo terminal, com o caractere “A”, 'B' 


ou “C”, respectivamente. 


3.5 APLICATIVOS EM C++ DE GERENCIMENTO REMOTO 


Em termos gerais, define-se uma corrente de ferramentas como um conjunto complexo de 
componentes de software. Coletivamente, eles traduzem código-fonte de programação em código 
de máquina executável. O GCC (GNU Compiler Collection, do inglês) é uma corrente do tipo open- 
source — código aberto — capaz de realizar todo o procedimento referido na Figura 3.14. Em ambi- 
ente Linux, os comandos gcc para C e sua contraparte g++ para C++ são na verdade os compila- 
dores mais próximos do ideal para tais linguagens, visto sua precisão sintática e semântica (BER- 


TOLOTTI; HU, 2016). 
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Figura 3.14 — Corrente de ferramentas típica, no caso através do GNU GCC no Linux. 
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Fonte: Bertolotti; Hu (2016). 


3.5.1 LINHA DE COMANDO PELO GNU GCC 


No Ubuntu Linux, a instalação dos pacotes gcc e g++ dá-se pela inclusão, no sistema, de 
um pacote denominado build-essential. Opcionalmente, pode-se instalar individualmente cada um 
deles ou utilizar as versões padrões que já vem com o Ubuntu. Esses procedimentos são normal- 
mente feitos pela interface terminal do Linux, que é a mais fundamental entre as interfaces de usu- 
ário disponíveis no sistema operacional. 

Ao executar uma corrente de ferramentas apropriadamente, tal como gcc ou g++, obtém- 
se arquivos que são executáveis pela interface terminal do sistema, considerando que tais códigos 
teriam sido escrito nas linguagens puras C e C++, ou seja, sem aditivos como frameworks. Inclu- 
sive, muitas das funções da linguagem C ou métodos da linguagem C++ foram planejados tendo 
em vista essas aplicações específicas por terminal, que existem em qualquer sistema — Linux, Win- 


dows, Mac OS X, entre outros — (BERTOLOTTI; HU, 2016). 
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Figura 3.15 — Feitura de executável por um arquivo escrito em C, no Ubuntu 7. 


Ubountuoubonto; = 


Datei Bearbeiten Ansicht Terminal Reiter Hilfe 


ubuntuQubuntu:-$ cat Hallo-Welt.c 
ginclude <stdio.h> 


int main(void) 

! 
printf("Hallo Welt!in"); 
return 0; 


> 


ubuntuQubuntu:-$ gec --version 

gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) 

Copyright (C) 2006 Free Software Foundation, Inc. 

Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es 

gibt KEINE Garantie; auch nicht fúr MARKTGÂNGIGKEIT oder FÚR SPEZIELLE ZWECKE. 


ubuntuQubuntu:-$ gcc Hallo-Welt.c 
ubuntuGubuntu:-$ ./a.out 

Hallo Welt! 

ubuntuGubuntu:-s E 


Fonte: Ladenthin (2017). 


Na Figura 3.15, um arquivo com um código básico escrito em linguagem C é criado com o 
comando cat do Ubuntu Linux. Logo em seguida, o comando gcc é executado com a opção — 
version, mostrando que a versão do mesmo é a 4.13. Finalmente, o programa gcc é aplicado 
como comando no arquivo de extensão .c referido anteriormente, o que gera um executável Linux 
denominado a.out, um nome clássico. Via terminal, sua execução é realizada ao anexar a expressão 


“./? ao nome de arquivo, o que força o console a rodar certo arquivo binário. 


3.5.2 INTEGRAÇÃO NO IDE CODE::BLOCKS 


Um software IDE o qual é tanto multiplataforma — Windows, Linux, Mac — quanto de có- 
digo-aberto, além de ter vasta documentação, é o chamado Code::Blocks, para C, C++ e Fortran. 
Em versões recentes do Ubuntu, ele pode ser adquirido por PPA — caminho de instalação específica 


por terminal — através do software Terminal. Sua capacidade abrange desde programas simples no 
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estilo terminal até interfaces gráficas completas com GTK+ e wx Widgets. Ainda, o IDE suporta um 
compilador GCC e um depurador GNU totalmente em várias plataformas. Essas qualidades do 
Code::Blocks fazem desse pacote uma etapa central para construir aplicativos diversos para o 


Ubuntu Linux ou até mesmo para outros sistemas operacionais (MODAK, 2013). Ver Figura 3.16. 


Figura 3.16 — Tela do Ubuntu Linux 14.04 com o Code::Blocks em depuração. 


= 4) 12:15 3 
fo) EBug a à à q; B E 
<global> E z 
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* Qworkspace 5 
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Y E sources 5 | int main(void) Example 
E 6 los Testing ! 
main.cpp = std: :cout << "Testing !" << std: :endl; 
8 std::cin.get(); 
9 return 0; 
10 dg 
nu 
Logs & others 


* 4 Closed files list 9€ À CppCheck 98 À CppCheck messages 988 A Cccc M€  Debugger 9% 9 Build log 3 | Build messages 9% À DoxyBlocks 96 O Thread search 9% 


Process terminated with status O (6 minute(s), 6 second(s)) 
O error(s), O wamning(s) (8 minute(s), O second(s)) 


eocno Run: Debug in Example (compiler: GNU GCC Compiler)---- 


atio 
LD 


for ce: /home/rjtrindade/Docu ons/Example/b /Exemple 
q: xterm -T Example -e /usr/bin/cb LIBRARY PATH=SLD LIBRARY PATH:. /hone/r)trindade/Docunents/Applications/Example/bin/Debug/Example (in /home/rjtrindade/Docunents/Applications/Example/.) 


»/Applications/Example/main.cpp Unix (LF) UTF-8 Line 1, Column 20 Insert Read/write default E 


Fonte: Jesner (2017). 


Um projeto é um importante conceito no IDE Code::Blocks, que pode ser descrito como 
uma coleção de arquivos fonte, ou source, e focos de construção. Um foco ou target pode ser 
definido como uma etiqueta para cada arquivo fonte, que contém um conjunto separado para op- 
ções de construção: compilador, vinculador e compilador de recursos. Durante a compilação de um 
projeto, o Code::Blocks seleciona o foco ativo, posteriormente construindo conforme as opções 
desse foco. Um projeto requere no mínimo um foco e um source para compilar. A Figura 3.17 


ilustra a estrutura de um projeto (MODAK, 2013). 
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Figura 3.17 — Árvore estrutural de um projeto genérico no IDE Code::Blocks. 


Target 1 Target 2 Target 3 


Fonte: Modak (2013). 


3.5.3 LIGAÇÃO USB EM AMBIENTE LINUX 


O sistema operacional previne aplicações de acessarem diretamente o hardware USB. Apli- 
cações precisam do acesso ao hardware USB através de um driver — software — para que o sistema 
operacional atribua ao dispositivo conectado a uma porta em particular. O driver então se comunica 
com outros de mais baixo nível, que por sua vez manejam a comunicação no barramento 
(JOUANEH, 2013). 

Apesar de um conector USB em um PC ser chamado de porta, ele difere das demais portas, 
como a porta serial R$-232. A diferença principal é que uma porta USB é parte de um sistema de 
barramentos, enquanto a porta serial é um circuito I/O com endereço específico de localização. 
Inclusive, para PCs que não possuem porta serial, é possível operar uma porta USB como se fosse 
R$S-232 padrão. Isso é alcançado fazendo o conector USB aparentar ser uma porta COM — RS-232 
— para o software no computador de host. 

Quando o device anexa-se à porta USB, o PC busca por um arquivo de informação, que 
especifica o driver que o PC usará com o dispositivo e carregará. Em todas subsequentes conexões 
do device ao host, o host passa por um processo de enumeração. Com isso, nesse procedimento, o 


host solicita informação do device de modo a referenciar o driver correto ao se comunicar com o 
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dispositivo. No processo de enumeração, o host requere informação do dispositivo, atribui um en- 
dereço ao dispositivo e seleciona uma configuração que reflita os requerimentos de potência e in- 


terface do equipamento device (JOUANEH, 2013). 
Figura 3.18 — Código em linguagem C no Code::Blocks para leitura pela porta USB. 


ginclude <stdio.h> 
ginclude <sys/ioctl.h> 
ginclude <unistd.h> 
ginclude <fcntl.h> 
ginclude <termios.h> 


int main(void) SerialRead 
12 
int Connect = open("/dev/ttyACMO", O RDWR | O NOCTTY); BCDABCDABCDA 
struct termios Options; , E PER DO DEE aÃ 
tcgetattr(Connect, &Options); ENTER-tO continue ES 


cfsetispeed(&Options, B9600); 
cfsetospeed(&Options, B9600); 
Options.c cflag &= -PARENB; 


Options.c cflag & -CSTOPB; 
Options.c cflag & -CSIZE; 
Options.c cflag |= CS8; 
Options.c cflag & -CRTSCTS; 


Options.c cflag |= CREAD | CLOCAL; 
Options.c iflag & -(IXON | IXOFF | IXANY); 
Options.c lflag & -(ICANON | ECHO | ECHOE | ISIG); 
Options.c oflag &= -OPOST; 

Options.c cc[VMIN] = 12; 

Options.c cc[VTIME] = 0; 

tcsetattr(Connect, TCSANOW, &Options); 
usleep( 1000000); 

tcflush(Connect, TCIFLUSH); 

static char Result[32]; 

int Size = read(Connect, Result, 32); 
printf("Bytes: “din”, Size); 
printf("Retorno: “sin”, Result); 

return 0; 


Fonte: Jesner (2017). 


A manipulação de dispositivos I/O terminais, como teclados e impressoras, é uma área obs- 
cura, sendo que isso não é exceção no sistema Unix e derivados, como o Linux. Essa área pode ser 
dividida em dois distintos modos de operação: os modos de processamento de entrada canônico e 
não-canônico. No primeiro, a entrada terminal é processada como linhas, com o driver ou software 
do dispositivo físico retornando no máximo a cada linha lida. Já no segundo, os caracteres de en- 
trada não são montados em linhas. Em geral, o modo padrão de uso é o canônico, com cada leitura 
retornando no máximo uma linha (STEVENS; RAGO, 2013). 

Na Figura 3.18, trabalha-se com um código C para aplicação terminal ou console. Em prin- 


cípio, as bibliotecas incluídas no topo do arquivo, com exceção da padrão stdio.h, vêm da API 
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do Linux, necessárias para o interfaceamento periférico no sistema. Dentro da função de entrada 
main, a função open é aplicada sobre um diretório chamado “/dev/ttyACMO”, que poderia 
inclusive ser “/dev/ttyUSBO”, com o “0º passível de ser qualquer número, conforme a quanti- 
dade de devices conectado ao host. Trata-se de uma referência ao arquivo do sistema Linux que 
controla a recepção de dados brutos — raw data — através de uma porta USB. A função open é 
iniciada com as opções O RDWR e O NOCTTY que, nessa ordem, definem operações alternadas de 
leitura e escrita e independência do processo em relação à porta. 

Considerando uma instalação USART-USB conectada ao PC, uma série de linhas são ro- 
dadas para trabalhar com as constantes PARENB, CSTOPB, CSIZE e CS8. Estas definem que a trans- 
ferência por barramento deve ser de pacotes com tamanho fixo de 8 bits, sem bits de paridade e 
nem de parada. O manejo com CRTSCTS refere-se à ausência de limitação de fluxo de hardware, 
enquanto com CREAD e CLOCAL habilita recepção e ignora linhas de status. Fluxos de entrada e 
saída, além de caracteres de reinicialização são desabilitados com IXON, IXOFF e IXANY. Final- 


mente, as constantes ICANON, ECHO, ECHOE, ISIG e, por, último, OPOST são manipuladas para, 


respectivamente, garantir um modo não-canônico, eco desabilitado, caracteres não-apagados, re- 
moção de sinais gerados terminalmente e saída com processamento desativado (HEYDRICK, 
2013). 

A alteração da estrutura de dados Options através dos índices VMIN e VTIME efetua o 
bloqueio do dispositivo até a leitura de 12 caracteres, sem um tempo de espera mínimo para o 
retorno da operação de leitura com read, feita posteriormente. A função tcsetattr, então, força 
as opções definidas sobre a conexão USB pelo arquivo do sistema. Isso é seguido pela espera do 
reinício do sistema embarcado, uma medida de segurança para muitos casos, pois começa a requi- 
sição elétrica através dele. Consequentemente, para a conclusão do preparo à operação de leitura, 
ocorre a limpeza do buffer serial por meio da função tcflush (HEYDRICK, 2013). 

Usando um vetor de 32 bytes, a leitura do sistema retorna, na Figura 3.18, o seguinte: 
“BCDABCDABCDA”. Considerando que o sistema embarcado anexado à porta USB do PC foi 
programado para enviar continuamente a expressão “ABCD” via USART, conclui-se que a leitura 
pela aplicação, de dentro do sistema Ubuntu Linux, foi realizada com sucesso, pois bastaria apro- 


priada filtragem para igualar a mensagem enviada com o ideal a ser recebido. 
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3.5.4 COMANDOS REMOTOS USB EM LINUX 


É possível empregar o mesmo código de leitura, tendo apenas algumas modificações, para 
uma troca de dados baseada em comandos a partir do Linux até o sistema embarcado, em que ele 
efetuaria determinadas ações. Como é evidenciado na Figura 3.19, são requeridas somente certas 
opções de comunicação com o driver USB do Linux, além de haver a troca da função read de 
verificação pela função write de imposição, obviamente. 

O código é iniciado com a declaração de várias variáveis auxiliares. Depois, com a função 
usleep, espera-se por determinado tempo a reinicialização do sistema embarcado, o que é muito 
comum, especialmente nos baseados na tecnologia AVR de microcontroladores. O controle da 
porta USB é feito seguramente em modo de bloqueio, havendo a possibilidade de fazer leituras 
sucessivas consumindo somente uma ação de reinício (HEY DRICK, 2013). 

Após a aplicação das configurações, a função write, na Figura 3.19, envia por USB um 
único caractere, o zero, especificando seu tamanho como unitário. Considerando que um sistema 
microcontrolado estivesse, na porta USB, programado para enviar uma mensagem quando rece- 
besse pelo barramento um único caractere ou bloco de 8 bits, tem-se que tal funcionalidade é al- 
cançada com sucesso pelo código €, pois a mensagem “HELLO” chega sem problemas na interface 


criada em Linux (HEYDRICK, 2013). 
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Figura 3.19 — Código em linguagem C no Code::Blocks para escrita pela porta USB. 


ginclude <stdio.h> 
ginclude <unistd.h> 
ginclude <fcntl.h> 
ginclude <termios.h> 
ginclude <errno.h> 
ginclude <sys/ioctl.h> 


SerialTrade 


: HELLO 


int main(void) P 0] execution time 4 
) ecution time + 


int Connect, Size; 

char Result[32] = (0); 

struct termios Options; 

Connect = open("/dev/ttyACMO", O RDWR | O NOCTTY); 
usleep(3500000) ; 

tcgetattr(Connect, &Options); 
cfsetispeed(&0ptions, B9600); 
cfsetospeed(&0ptions, B9600); 
Options.c cflag &- -PARENB; 

Options.c cflag & -CSTOPB; 

Options.c cflag &- -CSIZE; 

Options.c cflag |= CS8; 

Options.c lflag |= ICANON; 
tcsetattr(Connect, TCSANOW, &Options); 
write(Connect, "0", 1); 

Size = read(Connect, Result, 32); 
Result[Size] = 0; 

printf("Bytes: “din”, Size); 
printf("Retorno: “sin”, Result); 
return 0; 


Fonte: Jesner (2017). 


Dominados os diferentes aspectos da Linux API para gerenciamento USB, amplia-se a gama 
de possibilidades quanto à criação de aplicações de atuação e sensoriamento remoto, a partir do 
Linux, no tocante a sistemas embarcados com a tecnologia de microcontroladores. A título de 
exemplificação, uma interface gráfica completa em ambiente Linux poderia ser desenvolvida para 


controlar as funções de um robô conectado via barramento USB. 
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4 DESENVOLVIMENTO: INTERFACE GRÁFICA DE SISTEMAS EMBARCADOS 


Neste capítulo, serão apresentados técnicas para programação de interfaces gráficas, classes 
de componentes visuais do GTK+ wxWidgets e códigos de interfaces gráficas que estabelecem 
conexões USB com sistemas embarcados AVR. Finalmente, situações completas, além de próxi- 
mas da realidade, de interfaces em programação são discutidas em detalhes para melhor compre- 


ensão sobre o assunto. 


4.1 UTILIZANDO A LINGUAGEM C++ 


O desenvolvimento de um aplicativo constituído de uma interface gráfica de usuário é, em 
geral, uma tarefa abstrata e complexa. As ações de quaisquer usuários devem ser previstas pelo 
projetista, além de, em termos de códigos de programação, adequadamente mapeadas. É frequente 
também a necessidade de acesso a funções características do sistema operacional, como o controle 
de periféricos: mouse, teclado, impressora etc. 

Todos esses requisitos para a programação de uma interface gráfica, tanto no Linux quanto 
em outros sistemas operacionais, implicam na adoção de uma linguagem robusta e completa para 
a escrita dos códigos de computador. Atualmente, a aplicação das linguagens de programação de 
alto nível com orientação a objetos, pela sua proximidade virtual com o comportamento humano, 
é frequente em situações de propósito geral, em especial Java e CH. 

Contudo, para um sistema embarcado e uma análise minuciosa da comunicação entre este 
e um computador pessoal, deve-se escolher a linguagem C++ de Bjarne Stroustrup. Esta inclui em 
seu amplo escopo grande parte da linguagem C, que programa microcontroladores como o PIC e o 
AVR, além de incluir recursos de alto nível como a orientação a objetos. No ambiente Linux, em 
que há uma API de controle de portas USB escrita em C, a linguagem C++ torna-se ideal, pois 
permite um interfaceamento de caráter humano a tais códigos de hardware. Ainda, com o C++ 
obtém-se uma organização facilitada de uma interface gráfica feita do GTK+ wxWidgets, envol- 
vendo dados e eventos — clique em um botão, inserção em um campo de texto — de uma GUI 


genérica dentro do paradigma orientado a objetos. 
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4.1.1 EXECUTÁVEL CONSTRUÍDO NO UBUNTU LINUX 


No sistema operacional Ubuntu Linux, a biblioteca C++ multiplataforma wxWidgets traba- 
lha especificamente com o pacote GTK+ de processamento gráfico. O arquivo feito para execução 
nativa pode ser dependente da instalação de certos aditivos, da Figura 4.1, ou independente destes, 
sendo, então, denominado executável standalone. É importante notar isso pela evidente necessi- 


dade de sincronização existente entre o wxWidgets e qualquer sistema operacional. 


Figura 4.1 — Conjunto de requisitos para a execução do wxWidgets 3.0.0 no Ubuntu 14.04 (64-bit). 


libwxbase3.0-0 | libwxbase3.0-0- libwxbase3.0-dev libwxgtk3.0-0 3.0.0- 

3.0.0-2 amd64.deb  dbg 3.0.0-2 amd64.  3.0.0-2 amd64.deb 2 amdé64.deb 
deb 
libwxgtk-media3.0- wx3.0-examples . wx3.0-headers wx3.0-i18n 3.0.0-2 
dev 3.0.0-2 amdé64. 3.0.0-2 all.deb 3.0.0-2 amd64.deb alldeb 
deb 
libwxgtk3.0-0-dbg . libwxgtk3.0-dev | libwxgtk-media3.0- | libwxgtk-media3.0- 
3.0.0-2 amd64.deb 3.0.0-2 amd64.deb 0 3.0.0-2 amdé64. O-dbg 3.0.0-2 . 
deb amd64.deb 


e ima 
wx-common 3.0.0-  wxwidgets3.0 3.0.0. 
2 amdé64.deb orig.tar.bz2 


Fonte: Jesner (2017). 


A construção de um arquivo constituído por interface gráfica, como na Figura 4.2, que por 
fim é rodado em ambiente Linux, é possível através de um projeto wx Widgets no IDE Code::Blocks. 
Isso facilita a inclusão de arquivos para compilação e vinculação no g++, compilador para C++ no 
Linux, que é integrado ao Code::Blocks. Ainda, o IDE fornece dispositivos RAD (Rapid Applica- 
tion Development, do inglês) para componentes gráficos serem posicionados e associados a códigos 


de programação de forma otimizada. 
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Figura 4.2 — Executável, criado por um projeto wxWidgets no Code::Blocks, rodando no Linux. 


wxHello, 


Fonte: Jesner (2017). 


Como a Figura 4.3 ilustra, ao utilizar o sistema RAD no IDE Code::Blocks, ficam acessíveis 
e disponíveis diversos widgets ou ferramentas do Linux GTK+, o que inclui botões, etiquetas, pai- 
néis, barras de progresso, entre outros controles de formulário. Na decisão de uso de quaisquer 
dessas opções para interfaces gráficas, é gerado um código padrão em C++ para acesso a eventos 


do componente visual, facilitando a programação do comportamento do mesmo. 
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Figura 4.3 — Aparência do RAD em projeto gráfico wxWidgets 3.0.x no IDE Code::Blocks. 


Gauss Lt % mB qm» 4 S| Debug > he E 


Management 


4 Files Resources 


EF 
* JÁ Resources 


v ME wxHello = = 


E ES 
v Elwxrrame dana PO RER E an bu dp De aU Saad duda Sai an ns 


Y ElwxHelloFrame 
» ElwxFrame 
» GQ Tools 


= 
«9 
Title BR SETRARRR ARE ESSES an Ae EE 
Centered "FFP CMWM-k 
PESA ck to add Standard | Advanced | Aui | Contrib | Dialogs KWIC | Layout | Led | MathPlot | Tools 
Dera pos BD BUBEBBRBPUBAPOBOBEBHUHBEE: 
Logs & others 


“ Acc XX & Debugger 9 9 Build log % | P Build messages X À DoxyBlocks 9€ A Thread search 9€ 


Default size 
Width 
Height 

Size in dialc 
Enabled 


wxsmith/wxHelloframe.wxs default E 


Fonte: Jesner (2017). 


4.1.2 ADAPTAÇÕES EM CÓDIGOS C++ ABSTRATOS 


A linguagem de programação C++ possui elementos de orientação a objetos através dos 
quais é viável encapsular códigos e assim delimitar escopos de aplicação. Esse fenômeno ajuda a 
identificação e organização de códigos em geral, além de facilitar sua usabilidade periódica. Diz- 
se, por isso, que a orientação a objetos é uma evolução do paradigma modular, que pressupõe a 
divisão de um código principal em vários módulos ou arquivos de inclusão. A estruturação orien- 
tada a objetos é ilustrada na Figura 4.4. 

No framework C++ wxWidgets, os eventos associados aos componentes visuais são progra- 
mados através de métodos ou funções de classes de objetos. Ainda, suas propriedades e funciona- 


lidades são implementadas conforme objetos próprios de cada componente, o que é apropriado para 
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técnicas como a herança de atributos e o polimorfismo de métodos. Nesse contexto, pelo vasto 
poder léxico e semântico da linguagem C++, verifica-se expansibilidade e flexibilidade para com 


uma interface gráfica de usuário projetada. 
Figura 4.4 — Código básico em C++ com orientação a objetos visando interação com o wxWidgets. 


wxExampleMain.cpp 96 
82 


84 void wxExampleFrame: : OnQuit (wxCommandEvent& event) 
8 EM 
86 [ Close(); 

k 


92 class Message 
93 E 
94 public: 

95 | Message(void) LJ 

96 void ShowInfo (void) 

97 in ft 

98 wxMessageBox( ("Hello World !"), ("Hello World !")); 


105 void wxExampleFrame: :OnButtonlClick(wxCommandEvent& event) 
106 EM 

107 Message *msg = new Message(); 

108 msg->ShowInfo(); 

109 delete msg; 


Fonte: Jesner (2017). 


4.1.3 PADRÕES NA INTERFACE A SISTEMAS EMBARCADOS 


Um design pattern ou padrão de projeto é, em programação orientada a objetos, uma técnica 
de aplicação em códigos, que pode ser referente a diferentes aspectos destes, como os processos de 
instanciar objetos ou de derivar subclasses a partir de classes já escritas. Em termos simples, trata- 
se de um artifício que é fundamental e de frequência nesse paradigma de programação. No campo 
das interfaces gráficas em C++, verifica-se a utilidade de vários dos design patterns clássicos, como 


o Factory, o Singleton e o Dependency Injection. Ainda, com a presença de códigos para sistemas 
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embarcados em C dentro do código da interface gráfica em C++, tais meios são responsáveis por 


alcançar distintos níveis abstratos de similaridade com o raciocínio do ser humano. 
4.1.3.1 FACTORY 


A título de exemplificação, o padrão da programação orientada a objetos denominado Fac- 
tory desempenha o papel de criar classes de controle para que essas envolvam subclasses, de rele- 
vância para o sistema de software, e gerenciem objetos para estas. Essa segmentação auxilia na 
correção de erros no programa, no desenvolvimento de novas funcionalidades e, por fim, na com- 


preensão dos códigos por outros profissionais da área. 


Figura 4.5 — Respostas, no Ubuntu, de um sistema de mensagens que aplica o design pattern Factory. 


System warning! System error! 
w Please wait! — The software has stopped ! 


Fonte: Jesner (2017). 


Um sistema de mensagens por caixas pode ser desenvolvido com o wxWidgets, assim im- 
plementado simultaneamente para diversos sistemas operacionais. O padrão Factory em C++, no 
caso, é útil para a organização de diferentes categorias possíveis de mensagens gráficas que devem 
ser emitidas, em diferentes situações, ao usuário do computador. Duas mensagens, uma de aviso e 
outra de erro, são exibidas na Figura 4.5. O código das mesmas, pelo design pattern Factory, é 


detalhado na Figura 4.6. 
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Figura 4.6 — No IDE Code::Blocks, o design pattern Factory em C++ para um sistema de mensagens. 


wxExampleMain.cpp 36 


93 class Message 

Mm EM 

95 public: 

96 virtual void Show(void) = 0; 

97 virtual -Message(void) () 

Ba =); 

99 

100 class Warning : public Message 

101 f 

102 public: 

103 | void Show(void) (  wxMessageBox( ("Please wait !"), ("System warning !"), wxICON EXCLAMATION) ; ; 
104 Lt; 

195 

106 class Error : public Message 

107 Ef 

108 public: 

199 | void Show(void) (  wxMessageBox( ("The software has stopped !"), ("System error !"), wxICON ERROR); : 
110 Lt; 

111 

112 class Factory 

113 4 

114 public: 

115 static Message *HandleMessage(const std::string &param) 
116 — f 

17 | if(param == "Warning") return new Warning(); 
118 if(param == "Error") return new Error(); 
119 return NULL; 

120 E ) 

121 Lt; 

122 

123 void wxExampleFrame: : OnButtonlClick(wxCommandEvent& event) 
124 — 

125 Message *warning = Factory: :HandleMessage("Warning"); 
126 warning->Show() ; 

127 Message *error = Factory::HandleMessage("Error"); 

128 error->Show(); 

129 delete warning; 

130 delete error; 

131 J 

132 E 


Fonte: Jesner (2017). 


4.1.3.2 SINGLETON 


Além do padrão Factory, o clássico design pattern Singleton e seus derivados são dos mais 
relevantes para a manutenção de interfaces gráficas de usuário orientadas a objetos e eventos. Estes 
basicamente servem para criar variáveis globais e estáticas, porém restritas a escopos ou locais de 
códigos em que um objeto é instanciado para uma classe que, para todo o sistema de software, é 
fixa na memória. Apesar de serem muito empregados, sua aplicação moderna é controversa devido 
às atuais alternativas que eliminam, da lógica da programação de computadores, os estados mutá- 


veis, como as linguagens funcionais Python e Haskell. 
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Em particular, com o C++ e o framework wx Widgets, nos eventos de formulário, que são 
representados por métodos ou funções internas de classes, muitas vezes é necessário um estado de 
memória que se mantenha mesmo após um evento ser encerrado. Uma variável estática, em lin- 
guagem de programação, serviria para isso, mas esta não pode ser facilmente transferida para outro 
escopo facilmente a não ser que seja global. 

No entanto, as variáveis globais são passíveis de, sem nenhum problema de compilação, 
simplesmente participarem ou serem modificadas em locais indesejados do projeto. Nessas situa- 
ções, entra em ação o padrão Singleton da orientação a objetos, que pode ser ilustrado pelas Figura 


4.7 e 4.8 em um sistema que modifica um valor de O para 85 na primeira vez que o programa roda. 


Figura 4.7 — Respostas, no Ubuntu Linux, da aplicação do padrão estático na memória, o Singleton. 


Fonte: Jesner (2017). 
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Figura 4.8 — Código em C++, na plataforma wxWidgets, que emprega o design pattern Singleton. 


wxExampleMain.cpp 96 


90 

91 

92 

93 class Singleton 

94 Es 

95 public: 

96 static Singleton +Access(void) 

97 — f 

98 | static Singleton * const refer = new Singleton(); 
99 return refer; 

100 E k 

101 virtual int GetValue(void) 

102 — f 

103 return this->Val; 

104 [a 

105 1 virtual void SetValue(const int &param) 
196 Em f 

197 | this->Val = param; 

108 - ; 

109 private: 

no | int Val; 

11 Singleton(void) 

n2 O í 

113 this->Val = 0; 

114 - ) 

115 à dr 

116 

117 

118 

119 

120 void wxExampleFrame: : OnButtonlClick(wxCommandEvent& event) 
21 Bl 

122 std: :ostringstream msg/2]; 

123 | Singleton *first = Singleton::Access(); 
124 msg(0] << first->GetValue(); 

125 wxMessageBox(msg[0].str(), ("Value")); 
126 first->SetValue(85); 

127 Singleton *second = Singleton: :Access(); 
128 msg[1] << second->GetValue(); 

129 wxMessageBox(msg[1].str(), ("Value")); 
130 -J 

131 


Fonte: Jesner (2017). 


4.1.3.3 DEPENDENCY INJECTION 


Por fim, pode-se citar como exemplo de aplicação dos padrões de projeto o chamado De- 
pendency Injection, que trabalha com a ideia de desacoplamento de dados entre diferentes locais 
de um código de programação orientada a objetos. Isso facilita muito a verificação da execução do 


software a qual assim pode ser efetuada por unidades. O conceito de unit testing, nesse contexto, 
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assimila-se ao isolamento entre circuitos elétricos a fim de checá-los um por um, sem que haja 
interferências dos demais. 

O sistema da Figura 4.9 representa uma estrutura de várias mensagens de usuário distintas, 
como já foi trabalhado antes no design pattern Factory. Entretanto, no caso, além de um método 
de criação de objetos conforme subclasses, existe ainda uma classe de códigos extra. O propósito 
desta é, junto com a classe primária de funcionamento, a qual é conhecida como interface, cumprir 
o foco original do projeto, mas separando parâmetros de execuções. 

Verifica-se que o parâmetro cujo valor atribuído foi “Question” participa de um escopo, 
o da classe DependencyInjection, diferente do que invoca o método de exibição na subclasse, 
no caso a classe Showing. O referido código da Figura 4.9, portanto, é uma simples injeção de 


dependência para a manipulação eficiente de mensagens gráficas com wxWidgets. 
Figura 4.9 — Exemplo de participação do padrão Dependency Injection em um sistema simplificado. 


wxExampleMain.cpp 96 


9 class Messages 

92 

93 public: 

94 | virtual void Show(void) = 0; 

95 virtual -Messages (void) O 

asno =); 

97 

98 class Question : public Messages 

99 f 

100 | public: 

101 void Show(void) ( wxMessageBox( ("How are you ?"), ("How are you ?"), wxICON QUESTION); 5; 
102 LJ; 

103 

104 class Showing 

105 EM 

106 | public: 

197 I void ShowMessage (Messages *which) 4 which->Show(); + 

108 |); 

109 

110 | class DependencyInjection 

111 If 

12) | public: 

113 DependencyInjection(void) (  Inj = new Showing(); 3) 
114 -DependencyInjection(void) ( delete Inj; ) 

115 void Show(const std::string &param) Howareyou? 
po! * 

117 Messages *ask = new Question(); 

18 | if(param == "Question") this->Inj ->ShowMessage (ask); 

119 delete ask; ' 

2 [o 
121 private: 

122 | Showing *Inj; 

123 Lj; 

124 

125 void wxExampleFrame: : OnButtonlClick(wxCommandEvent& event) 

126 EM 

127 DependencyInjection msg; 

128 | msg.Show("Question"); 

129 

130 = 


Fonte: Jesner (2017). 
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4.2 FERRAMENTAS GRÁFICAS DO GTK+ 


Nos sistemas operacionais baseados no núcleo Linux, a biblioteca wxWidgets para C++ é 
implementada pelo conjunto GTK+ para processamento gráfico, o que significa que quaisquer 
componentes de uma interface gráfica nativa — botões, etiquetas, imagens — estão conectados ao 
trabalho do mesmo. Eles são os widgets ou ferramentas GTK+ do wxWidgets, que vão, sob a no- 
menclatura portável do wxWidgets, desde simples etiquetas em texto até avançadas integrações de 


códigos HTML (HyperText Markup Language, do inglês). 


4.2.1 COMPONENTES C++ VISUAIS E VIRTUAIS 


Entre os componentes standard, os básicos, do wxWidgets na versão 3.0 destacam-se para 


um iniciante: wxAnimationCtrl, wxButton, wxBitmapButton, wxCheckBox, wxChoice, 


wxComboBox, wxGauge, wxPanel, wxRadioBox, wxRadioButton, wxScrollBar, wxSlider, 
wxStaticBitmap, wxStaticText e wxToggleButton. Através desses modelos específicos, 
uma interface gráfica de usuário em aplicativo executável pode ser projetada de modo satisfatório. 


A Figura 4.10 ilustra a totalidade de componentes fundamentais do wx Widgets 3.0. 


Figura 4.10 — No Code::Blocks, barra de ferramentas do wxWidgets em ambiente Linux GTK+. 


Standard | Advanced | Aui Contrib Dialogs KWIC| Layout Led | MathPlot | Tools 


2 |9r Bens ear Scr BI ear | abe | em | fo | ES E 


Fonte: Jesner (2017). 


Um estudo detalhado de um desses componentes, arbitrariamente o painel wxPanel, é apro- 
priado para o presente trabalho. Um painel, na programação de formulários, é um objeto de impor- 
tância responsável por envolver outros, sendo que estes herdam automaticamente as propriedades 
— cor de fundo, visibilidade, habilitação — daquele. Por padrão, uma interface de wx Widgets deve 


ter como componente primário colocado um wxPanel, procedimento que é indicado na Figura 4.11 
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em um projeto recém-criado no IDE Code::Blocks. 


Figura 4.11 — Anexação de um componente visual wxPanel em uma nova interface no Code: :Blocks. 


Standard | Advanced | Aui | Contrib | Dialogs | KWIC | Layout | Led | MathPlot | Tools 


DEBCOBEPEDESSPEBEPoBodoBEDBEs 


Fonte: Jesner (2017). 


Com um novo componente do tipo wxPane1 incluído no projeto, vêm um conjunto de pro- 
priedades e eventos relacionados a ele, sendo que esses são variáveis e funções de uma classe para 
o modelo wxPane1. Como mostra a Figura 4.12, os atributos são modificáveis e estão presentes 
desde o começo da execução do novo aplicativo, enquanto os métodos para diferentes eventos 
precisam ser ativados individualmente para, com isso, serem chamados durante o processamento. 
Entre as propriedades, pode-se mencionar o Enabled que modifica os estados de habilitação dos 
componentes filhos do painel, como caixas de marcação, botões etc, assim fazendo com que o 
usuário possa ou não ter interação. Entre os eventos há, no wxWidgets, o representado por 
EVT KEY DOWN, chamado de OnkeyDown, que detecta o pressionamento de teclas quando o painel 


é selecionado pelo usuário. 
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Figura 4.12 — Tabelas, no Code::Blocks, com atributos e eventos do novo componente visual. 


(3 t+ 
Title 
Centered [] 
Icon Click to add 
Default pos 


EVT CLOSE -—None- 
EVT PAINT -—None- 
EVT ERASE -—None- 
EVT KEY DC OnPanelikeyD 
EVT KEY UF — None — 
EVT CHAR -—-None- 
Pos in dial: 


EVT SET FO — None — 
EVT KILL FC — None — 
EVT LEFT D —-None- 
EVT LEFT U —None-— 
EVT LEFT D —-None- 
EVT MIDDLE — None — 


Defaultsize | | 
Width 
Height 
Size in dialoc [ | 
Enabled 


Fonte: Jesner (2017). 


4.2.2 IMAGENS E PERSONALIZAÇÃO DA INTERFACE 


Em uma interface gráfica de usuário, a personalização acessível pelo indivíduo é uma ca- 
racterística que, se manipulada corretamente, intensifica a qualidade do sistema, com isso provo- 
cando aumento de demanda. Entre os componentes virtuais do wxWidgets, aqueles que servem para 
o controle de imagens são de ampla aplicação: ícones, fundos de painéis, botões com imagem aco- 
plada, animações diversificadas etc. Do ponto de vista genérico, as classes que trabalham, em pro- 
pósito geral, com imagens são wxStaticBitmap e wxImage. 

O modelo wxStaticBitmap serve para carregar uma imagem, em formato variado de 
compactação — BMP, JPG, PNG, GIF — a partir da memória de armazenamento do PC e, após isso, 
renderizá-la como um mapa de dígitos binários. É otimizado, mas afeta a qualidade da imagem 
projetada na interface gráfica, como é perceptível na Figura 4.13 cujo objetivo é representar o 
wxStaticBitmap em ambiente RAD. A classe wxImage, por sua vez, é mais complexa e carrega 
uma imagem na interface gráfica de usuário não através do RAD, mas por códigos de processa- 
mento gráfico. Isso significa que há possibilidade, no wx Widgets, de filtragens de imagens, varia- 


ções de opacidade, entre outras técnicas gráficas sofisticadas. 
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Figura 4.13 — Utilização da classe wxStaticBitmap para componentes visuais no Code::Blocks. 


Image editor 
Image options Preview 
No image 


O Image From File: 
/[homey/rjtrindade/Desktop/UFAC. |... Es 
) Image from wxArtProvider: F| 
ArtId: v 
Art Client: v ul! 


Code x 


Fonte: Jesner (2017). 


4.2.3 CONFIGURAÇÕES AVANÇADAS 


Dentre todos os componentes disponíveis no RAD do Code::Blocks para um projeto com 
o framework wxWidgets 3.0, há, além dos standard, aqueles que são para uso avançado na plata- 
forma em C++. Exemplos disso são: o componente wxImage, que escreve conforme uma biblio- 
teca para processamento gráfico; a classe wxColourPickerCtr1, que exibe uma tela de seleção 
de cores conforme números hexadecimais; o componente wxHtmlWindow, que integra os códigos 
HTML, como os usados em navegadores, na interface em aplicativo; etc. 

Como exemplo avançado de componente wxWidgets, a classe wxHtmlWindow pode ser 
empregada para a inserção simples de uma animação GIF (Graphics Interchange Format, do in- 
glês) na interface gráfica. Com um arquivo de dados da animação, a Figura 4.14 ilustra o uso da 
tag HTML <img> a fim de ter um componente personalizável, por diferentes configurações, para 


uma animação específica do tipo GIF. 
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Figura 4.14 — Componente wxHtmlWindow aplicado na integração de uma animação GIF por HTML. 


wxAnimMain.cpp 9€ | wxAnimframe.wxs 96 


=== 


x Ada 


Standard | Advanced | Aui | Contrib | Dialogs KWIC | Layout | Led | MathPlot | Tools 


jr Bona || mBjEjaIjeje|m|-|dra| os Abe | | o | foi) 


Fonte: Jesner (2017). 


4.3 À INTERFACE GRÁFICA DE UM SISTEMA ELETRÔNICO 


Nesta seção, serão tratadas técnicas de programação de interfaces em Linux para comuni- 
cação com sistemas com microcontrolador AVR via USB, tanto do ponto de vista dos códigos de 


GUIs quanto dos firmwares AVR. 


4.3.1 PROCESSAMENTO LIGADO ENTRE AVR E LINUX 


A comunicação entre o microcontrolador AVR, como o ATmega328P, e um PC vem da 
aplicação adequada da API do Linux, quando este é o sistema operacional vigente. Contudo, exis- 
tem problemas nos processos de leitura e escrita na ligação, que é frequentemente por barramento 
USB. É necessário, primeiramente, que o chip AVR não sofra reinicialização por vez em que ocor- 
rer um processo de transferência, mas sim somente na conexão com a porta USB do PC. 

Há técnicas eletrônicas de alcançar, por padrão, o efeito de não-reinicialização após a pri- 


meira vez, em se tratando de um sistema microprocessado com AVR. Contudo, existe uma maneira 
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simplificada: por programação conhecendo-se todas as entradas e saídas do sistema interligado 
entre AVR e Linux PC. A Figura 4.15 mostra um console em ambiente Linux que recebe dados de 
um AVR na porta USB, depois exibindo os mesmos para o usuário. Nota-se que a parte do código 
sobre configurações USB é mantida com somente uma execução, enquanto a parte de leitura tende 
a executar indefinidas vezes devido a um loop infinito. O firmware do AVR, escrito em C, é ilus- 


trado na Figura 4.16. 


Figura 4.15 — Código de um monitor, em console, de leituras de um microcontrolador AVR via USB. 


main.cpp 96 


ginclude <stdio.h> 
ginclude <sys/ioctl.h> 
ginclude <unistd.h> 
ginclude <fcntl.h> 
ginclude <termios.h> 


int main(void) 


int Connect = open("/dev/ttyACMO", O RDWR | O NOCTTY); 
struct termios Options; 

tcgetattr(Connect, &Options); 

cfsetispeed(&0ptions, B9600); = 
cfsetospeed(S0ptions, B9600); monitorAVR 
Options.c cflag &= -PARENB; AC 

Options.c cflag —-CSTOPB; 

Options.c cflag -CSIZE; 

Options.c cflag cs8; 

Options.c cflag -CRTSCTS; 

Options.c cflag CREAD | CLOCAL; 

Options.c iflag -(IXON | IXOFF | IXANY); 
Options.c lflag -(ICANON | ECHO | ECHOE | ISIG); 
Options.c oflag -0POST; 

Options.c cc[VMIN] = 12; 

Options.c cc[VTIME] = 0; 

tcsetattr(Connect, TCSANOW, &Options); 
usleep(1000000) ; 

tcflush(Connect, TCIFLUSH); 

for(;;) 


= f 


tira 


qr 


char Result[32] = (0); 
read(Connect, Result, 32); 
printf(Result); 


Ro 3 


return O; 


Fonte: Jesner (2017). 


O mesmo procedimento de ligação sem reinicialização é possível para a atividade de escrita, 
desde que os códigos fiquem sincronizados para manter a ligação USB estabelecida, o que implica 
conhecimento mútuo entre o firmware e o software de interfaceamento. Dessa maneira, funções 


como open e cfsetispeed seria sempre processada uma única vez: quando a interface em Linux 
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conectasse com a porta USB contendo o sistema AVR. 

Outro problema comum é o de ruído ou erros na transmissão USB, por várias razões, como 
desgastes de fiação, proteções do sistema operacional e diferenças de velocidade. Em geral, isso, 
contudo, pode ser resolvido aplicando métodos de correções de erros. Confirmar a transferência de 
dados através de várias repetições do mesmo pacote de informações é uma das técnicas mais apli- 


cadas nessa área. 


Figura 4.16 — Um firmware de monitor, em console, de leituras de um microcontrolador AVR via USB. 


include <avr/io.h> 


define F CPU 16000000UL 
define BAUD 9600 


finclude <util/setbaud.h> 


=jint main(void) 
í 

UBRRGH 
UBRROL 
UCSROA 
UCSROB 
UCSROC 
for(;;) 
! 


UBRRH VALUE; 
UBRRL VALUE; 
ebeeiooago; 
oboBal ioga; 
eboBaoai 1a; 


nom 


char Input[3][3] = 


E) 


BC) 
a 
z5 


for(int i =0; i<3; it) 
í 
for(int j = 0; j<3; jH) 
E! 
loop until bit is set(UCSROA, UDREG); 
UDRG = Input[il][5]; 


loop until bit is set(UCSROA, UDREO); 
UDRO = 'An'; 


Fonte: Jesner (2017). 
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4.3.2 LEITURA ELETRÔNICA PELA INTERFACE 


O processo de obtenção, no Linux, de mensagens provenientes de um AVR em porta USB 
é aplicável para a atualização do conteúdo de interfaces gráficas de controle. Quando a mesma é 
sustentada pelo framework wxWidgets, a classe disponível denominada wxT imer é apropriada para 
a situação, visto que permite interações USB sem, no entanto, pausar o resto do aplicativo em C++. 
A Figura 4.177 ilustra um código que atualiza um elemento StaticText em um formulário con- 


forme um temporizador wxTimer, sendo o AVR da Figura 4.16 a fonte das informações. 
Figura 4.17 — Formulário que atualiza, a cada 100 milissegundos, um texto conforme um AVR USB. 


readingaVRMain.cpp 96 


134 
135 static char Result[5]; 
136 
137 


138 void readingAVRFrame: : OnButtonlClick(wxCommandEvent& event) 000 


139 Eli 

140 static bool Once = false; 

141 if(!'Once) 

142 me f 

143 read(ConnectUSB, Result, sizeof(Result) - 1); 

144 TimerId = new wxTimer(this, AVR Timer); 

145 TimerId->Start (100); ” 
146 Once = true; AVR: [123] 
147 - ) 

148 Lj 

149 

150 

151 void readingAVRFrame: :OnTimerAVR(wxTimerEvent& event) 
152 If 

153 read(ConnectUSB, Result, sizeof(Result) - 1); 

154 std::string Text (Result); 

155 std::replace(Text.begin(), Text.end(), n', '1'); 

156 Text = "AVR: [" + Text; 

157 StaticTextl->SetLabel (Text); 

158 ; 

159 | 


Fonte: Jesner (2017). 


No caso do código da Figura 4.17, a primeira conexão USB, além das configurações de 
acesso, são realizadas implicitamente ao abrir o aplicativo de interface, com as variáveis em con- 
dições globais e estáticas. A partir daí, ao clicar no botão Connect, é inicializado um temporizador 
que automaticamente atualiza a interface a cada período de tempo, o que ocorre sem reinicializa- 
ções do sistema com AVR. Verifica-se a relevância da sincronização dos softwares nos sistemas 


microprocessados, pois com o AVR atuando mais rápido que a leitura da interface, valores novos 
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podem ser vistos pelo usuário no decorrer do tempo. 


4.3.3 ATUAÇÃO GRÁFICA NA INTERFACE 


A atuação de um sistema embarcado através de uma interface gráfica é realizada pelo pro- 
cesso de escrita por barramento USB. Para isso, o microprocessador escravo deve saber quais co- 
mandos receberia da interface para, assim, modificar os níveis lógicos em suas portas I/O conforme 
eles. Para não ocorrer travamentos ou reinicializações, o firmware AVR deve atualizar suas saídas 
conforme valores padrões ou estáticos, sendo que estes são úteis para gravar os dados atualizados 
mais recentes de uma porta mesmo que, no instante de tempo, não aconteça passagem de informa- 


ção via USB. 


Figura 4.18 — Um firmware de ATmega328P para três tipos de comando, com salvamento do último. 


include <avr/io.h> 


define F CPU 16000000UL 
define BAUD 9600 


ginclude <util/setbaud.h> 


=Jint main(void) 
t 

UBRROH 
UBRROL 
UCSROA 
UCSROB 
UCSRBC 
DDRB 
DDRC 


UBRRH VALUE; 
UBRRL VALUE; 


PORTB 
PORTC 
PORTD 
static signed char Output = -1; 
for(;5) 
t 
signed char Buffer; 
loop until bit is set(UCSROA, RXCO); 
Buffer = UDRO; 
if(Buffer >= 'B' && Buffer <= 'D') Output = Buffer; 
if(Output == 'B')  PORTB “= (1 << PB5); 
else if(Output == 'C') PORTC “= (1 << PC5); 
= "D') PORTD “= (1 << PD5); 


else if(Output = 


Fonte: Jesner (2017). 
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Na Figura 4.18, um código em C a ser gravado em microcontrolador AVR é exibido. De 
acordo com o valor lido do mecanismo USART do AVR, equivalente ao do USB enviado pelo PC 
com interface em Linux, as saídas do AVR seriam alteradas em três possibilidades. Começando 
com todas zeradas, as portas B, C e D — conjuntos de oito pinos I/O — seriam, pelo valor recebido 
da interface gráfica no Code::Blocks, modificadas para: acender o pino 5 da porta B; ligar o pino 
5 da porta C; e, por fim, acender o pino 5 da porta D. Isso ocorreria conforme o byte recebido via 


USART fosse, respectivamente, igual a *B”, *C” ou *D”, como mostra a Figura 4.19. 


Figura 4.19 — Interface gráfica de comandos para os pinos de um AVR ATmega328P em USB. 
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118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 


void writingAVRFrame: : OnQuit (wxCommandEvent& event) 
mil 
[ Close(); 

) Co 


void writingAVRFrame: :OnButtonlClick(wxCommandEvent& event) 
EM 

É write(ConnectUSB, "B", 1); 

; 


E D 
void writingAVRFrame: :OnButton2Click(wxCommandEvent& event) 


EX 
[ write(ConnectUSB, "C", 1); 
; 


void writingAVRFrame: : OnButton3Click(wxCommandEvent& event) 
E! 
| write(ConnectUSB, "D", 1); 


Fonte: Jesner (2017). 


4.4 PROPOSTA DE INTERFACE GRÁFICA EM LINUX AO ATMEL AVR 


Nesta seção, serão abordados dois exemplos de interface gráfica em Linux, contando com 
códigos de GUI em C++ e com códigos de AVR em €. Ao final, o leitor deverá estar apto a criar 


sistemas do tipo interface gráfica em Linux PC que se comunica com sistema embarcado via USB. 
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4.4.1 PARAMETRIZAÇÃO DE COMPORTAMENTOS 


Como exemplo completo, em C++, de aplicação de interface gráfica de usuário em Linux 


através do ATmega328/P, pode-se parametrizar os seguintes comportamentos: 


e Leitura de um sensor digital, com valores de O V — estado OFF — ou 5 V — estado 


ON - cuja condição é exibida e atualizada na interface gráfica; 


e Acionamento de um LED — buzzer, motor DC, entre outros — através de portas 
I/O do microcontrolador. Obs: A carga escolhida tem tensão nominal de 5 V e 


corrente de até 20 mA; 


e A medida que o sistema atualize a leitura do sensor, o usuário é requisitado a 


comutar ou não o estado do LED de saída. 


Esse projeto envolve ambas as operações de leitura e comando da interface gráfica, com o 


adicional de contemplar uma situação cotidiana na área de sistemas eletrônicos. 


4.4.2 CONVERSOR FT232R PARA TRANSFORMAÇÃO USART-USB 


Fabricado pela empresa FTDI (Future Technology Devices International, do inglês) Chip, 
o dispositivo eletrônico FT232R — FT232RL, FTDD32, FTDD32RL, FTDI BASIC — engloba uma 
série de circuitos de interfaceamento entre mecanismos USB e USART. Ele inclui uma geração de 
saída de clock opcional, além de ser simplificado para projetos em geral pela miniaturização de 
uma EEPROM externa, de circuitos síncronos e de resistores USB. A Figura 4.20 ilustra o compo- 


nente e sua pinagem. 
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Figura 4.20 — Componente físico FT232R e seus respectivos pinos no padrão COM de PCs. 


Fonte: NSK Electronics (2017). 


Através de um cabo USB apropriado, o dispositivo FT232R permite que um circuito ele- 
trônico qualquer com microcontrolador AVR ATmega328/P estabeleça comunicação com um 
computador pessoal (CAMPOS, 2015). As informações internas do AVR, então, são ligadas à me- 
mória do PC para posteriores processamentos. A Figura 4.21 ilustra a montagem de um FT232R 


em uma matriz de contatos, para o referido tipo de AVR. 


Figura 4.21 — Conexões elétricas a serem feitas para a utilização do FT232R da FTDI Chip. 


“e... ....... 


atmega3o2B 


“e... ....... 
“............ 


Fonte: Campos (2015). 
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A aplicação do FTDI Basic em sistemas com AVR em geral faz com que os sistemas mi- 
crocontrolados com comunicação USB tornem-se altamente profissionais, pois inclusive drivers 
são disponibilizados pela FTDI Chip para diversos sistemas operacionais para o uso do conversor: 


Windows, Mac, e, obviamente, Linux. 


4.4.3 PROGRAMAÇÃO DIRECIONADA NO AVR ATMEGA328P 


No microcontrolador ATmega328P, o código C do firmware sempre faz o ciclo: 


Passo 1. Ler o pino do sensor digital; 
Passo 2. Enviar um dado para a interface gráfica via USB; 
Passo 3. Esperar a resposta da interface, que seria na forma de um comando de escrita; 


Passo 4. Repetir o procedimento desde o primeiro passo. 


A Figura 4.22 ilustra esse processo em detalhes, com um código similar aos já descritos 


para leitura e escrita. 
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Figura 4.22 — O firmware em linguagem C para o ATmega328P relativo a uma interface completa. 


Somme Ho RS 


include <avr/io.h> = 


gdefine F CPU 16000000UL 
define BAUD 9600 


&include <util/setbaud.h> 


-jint main(void) 
í 

UBRROH 

UBRROL 


UBRRH VALUE; 
UBRRL VALUE; 


9b11111111; 


static signed char Input = -1; 

static signed char Output = -1; 
if(PINC & 1) Input = '1"; 

else Input = '0'; 

loop until bit is set(UCSROA, UDREO); 
UDRO = Input; 

signed char Buffer; 

loop until bit is set(UCSROA, RXCG); 
Buffer = UDRO; 

if(Buffer == '0' || Buffer == '1') Output = Buffer; 
if(Output == '0') PORTE & «1; 

else if(Output == '1') PORTB |= 1; 


Fonte: Jesner (2017). 


4.4.4 CONSTRUINDO A INTERFACE GRÁFICA DE CONTROLE 


A interface gráfica completa em C++ com wx Widgets deveria realizar os passos: 
Passo 1. Ler o valor do sensor através do barramento USB; 
Passo 2. Depois, requisitar ao usuário o novo estado do LED de saída; 


Passo 3. Finalmente, repetir o processo após a alimentação do LED ter sido definida. 


Na Figura 4.23, a interface gráfica é exibida em execução e em diferentes situações, sendo 


que a mesma aplica diversos tipos de componentes do wxWidgets: wxButton, wxStaticText, 
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wxStaticBitmap etc. 


Figura 4.23 — Todas as possibilidades da interface dinâmica de controle. Situações: (a) Caso com sensor em ON e 
LED apagado; (b) Caso com sensor em OFF e LED aceso; (c) Caso em que ambos estão desativados; (d) Caso em 
que ambos estão ligados. 


Õ 


(b) 


Õ 


(d) 


Fonte: Jesner (2017). 


Em termos de códigos de programação, tem-se em variáveis globais e estáticas os detalhes 
do acesso à porta USB com a Linux API. Com isso, quando o formulário é iniciado um temporiza- 
dor da classe wxTimer é criado e destinado a fazer repetidamente a leitura USB do AVR, que 
retorna a informação sobre o sensor digital. A cada leitura, contudo, o fluxo de orientação do código 
é pausado e continuado com a execução do evento de clique de um dos botões, sendo esse final- 
mente responsável pelo estado ON ou OFF do LED de saída. A Figura 4.24 termina o exemplo 


com algoritmos funcionais para essa aplicação wx Widgets, tomando a variável Processing como 
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global e booleana, além do vetor global auxiliar Result. 
Figura 4.24 — Algoritmos, no contexto, do vxWidgets, de interfaceamento completo com o AVR. 


void ExampleFrame: : OnTimerAVR(wxTimerEvent& event) 
! 
if(!Processing) 
! 
Buttonl->Enable(); 
Button2->Enable(); 
read(ConnectUSB, Result, sizeof(Result) - 1); 
if(Result[0] == '0') 
! 
Sensor->SetLabel ("SENSOR OFF"); 
Sensor->SetForegroundColour (wxColour(0xFF, 0x00, 0x00)); 


k 
else if(Result[1] == '1') 
! 
Sensor->SetLabel ("SENSOR ON"); 
Sensor->SetForegroundColour (wxColour(0x00, OxFF, 0x00)); 
k 
k 
Processing = true; 


k 
void ExampleFrame: : OnButtonlClick(wxCommandEvent& event) 


if(Processing) 

! 
FrameLED1->Hide(); 
FrameLED2->Show(); 
Buttonl->Disable(); 
Button2->Disable(); 
write(ConnectUSB, "1", 1); 
Processing = false; 


k 

k 

void ExampleFrame: : OnButton2Click(wxCommandEvent& event) 
if(Processing) 
! 


FrameLED1->Show() ; 
FrameLED2->Hide(); 
Buttonl->Disable(); 
Button2->Disable(); 
write(ConnectUSB, "0", 1); 
Processing = false; 


Fonte: Jesner (2017). 
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4.4.5 INTERFACE GRÁFICA DE CONTROLE EM TEMPO REAL 


A proposta de interface gráfica completa apresentada no item anterior, das Figuras 4.23 e 
4.24, exemplifica a comunicação USB de leitura e escrita, no Linux, entre interface e sistema mi- 
crocontrolado com AVR. Contudo, do ponto de vista do usuário, não está presente um efeito de 
concorrência ou paralelismo de funcionalidades, pois a informação do sensor na interface só atua- 
liza quando o usuário decide sobre a atuação. Isso dificulta a produção de um sistema combinado 
em tempo real. 

Entretanto, não há uma maneira de computação paralela na linguagem C até o C99, que é a 
versão mais recente aplicada nos microprocessadores. Assim, por mais que o PC com Linux e C++ 
suporte técnicas de caráter concorrente, o firmware em C do AVR não aceita as mesmas. A solução 
proposta, é deslocar a prioridade do sistema combinado para a interface gráfica, tornando a relação 
interface-microcontrolador similar à de mestre-escravo. Assim, a interface sempre solicita rapida- 
mente, de modo imperceptível ao usuário, leituras e escritas do sistema na porta USB, nunca este 
fazendo um envio ou recebimento por si próprio. 

A Figura 4.25 ilustra um firmware escrito para só fazer algo quando receber um comando 
ou caractere “Rº ou “Wº — seguido de “0” para parar e “1” para iniciar a atuação — pelo barramento 
USB de transferência. Se isso não acontece, o código é mantido em estado de espera até que receba 
o caractere proveniente da interface. Se esse processo é, com a tecnologia de processamento atual, 
agilizado a um ponto suficiente, tem-se que o intervalo de espera torna-se desprezível aparentando 
um trabalho em tempo real. 

A Figura 4.26, por sua vez, ilustra O software escrito em C++ da interface gráfica no Linux. 
O mesmo emprega um temporizador wxTimer para alcançar o efeito cíclico de verificação e lei- 
tura. Nesse código, entre a escrita — necessária para fazer o AVR ler um dado — e a leitura, é deixado 
um tempo de 10 milissegundos, por motivos de segurança. Há, ainda, o código do evento de ativa- 
ção de tecla, que é uma interrupção do fluxo principal. Ele usa a variável global Updating para 
memorizar o estado do atuador, mostrando-o ao usuário. 

Finalmente, a Figura 4.27 ilustra uma interface gráfica que dispõe de concorrência, do ponto 
de vista do usuário. Ao ser pressionada a tecla de barra de espaços, o atuador é ativado ou desati- 


vado, dependendo do seu estado anterior. Paralelamente, porém, a informação do sensor digital é 
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atualizada, indicando que a interface pode ler e escrever em tempo real. Observa-se que na imple- 
mentação da interface referida, está sendo utilizado um timer de 600 milissegundos determinado 
como o melhor experimentalmente. 

O presente método de produção de uma interface gráfica em Linux, com relação a um sis- 
tema de controle com sensores e atuadores, é aplicável e expansível para várias variáveis e dife- 
rentes configurações. Isso inclui controles manuais ou automáticos, com ou sem realimentação, em 
tempo real ou não, com paralelismo ou não etc. Tais possibilidades são limitadas tão somente pelos 
mecanismos de entrada-saída do microprocessador — AVR, PIC etc. — e pelos tempos necessários 
ao sistema combinado: período de clock dos microprocessadores, faixa de frequência do barra- 


mento de comunicação, entre outros. 
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Figura 4.25 — O firmware dependente de comandos de escrita específicos para operar. 


EE DO em 


finclude TES h> 


define F CPU 16000000UL 
define BAUD 9600 


finclude <util/setbaud.h> 


Hint main(void) 

t 
UBRRBH UBRRH VALUE; 
UBRROL UBRRL VALUE; 
UCSROA = GbBB100000; 
UCSROB = GbB0011000; 
UCSROC = ObB0BBOIIO; 
DDRB = Qb11111111; 
DDRC = GbBBBBBODA; 
PORTB eboagaagao ; 
PORTC = GbB0000000; 
for(;;) 
t 


auto signed char Input; 

static signed char Output; 

auto signed char Interface; 

loop until bit is set(UCSROA, RXCG); 
Interface = UDRG; 

if(Interface == 'R') 

! 


if(PINC & 1) Input = '1'; 
else Input = '0'; 
loop until bit is set(UCSROA, UDREB); 
UDRO = Input; 
: 
else if(Interface == 'w') 
1 
signed char Buffer; 
loop until bit is set(UCSROA, RXCO); 
Buffer = UDRO; 
if(Buffer == "9" || Buffer == '1') Output = Buffer; 
if(Output == '0') PORTE & nl; 
else if (Output == '1") PORTB |= 1; 


Fonte: Jesner (2017). 
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Figura 4.26 — Código da interface gráfica para um sistema combinado do tipo mestre-escravo. 


ApplicationMain.h 9€ |ApplicationMain.cpp 96 


146 

147 static int Updating; 

148 

149 

150 void ApplicationFrame: :OnTimerAVR(wxTimerEvent& event) 
151 3 

152 write(ConnectUSB, "R", 1); 

153 usleep(10000); 

154 char Result[2] = (0); 

155 read(ConnectUSB, Result, sizeof(Result) - 1); 

156 if(Result[0] == '0') 

157 H t 

158 Sensor->SetLabel ("OFF"); 

159 Sensor->SetForegroundColour (wxColour(0xFF, 0x00, 0x00)); 
160 E; 

161 else if(Result[0] == '1') 

162 = 1 

163 Sensor->SetLabel ("ON"); 

164 Sensor->SetForegroundColour (wxColour(0x00, OxFF, 0x00)); 
165 e i 

166 Lj 

167 

168 

169 void ApplicationFrame: :OnPanellkeyDown (wxKeyEvent& event) 
170 El 

171 if(event.GetkeyCode() == WXK SPACE) 

172 = f 

173 if(!Updating) 

174 = 1 

175 write(ConnectUSB, "Wl", 2); 

176 Actuator->SetLabel ("RUNNING") ; 

177 Actuator->SetForegroundColour (wxColour(0x00, OxFF, 0x00)); 
178 Updating = true; 

179 a E; 

180 else 

181 — f 

182 write(ConnectUSB, "Wo", 2); 

183 Actuator->SetLabel("STOPPED"); 

184 Actuator->SetForegroundColour (wxColour(0xFF, 0x00, 0x00)); 
185 Updating = false; 

186 e i 

187 H ; 

188 o 


Fonte: Jesner (2017). 
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Figura 4.27 — Interface gráfica de usuário com aplicação concorrente. A variação dá-se como na Figura 4.23. 


Fonte: Jesner (2017) 
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5 CONCLUSÕES E TRABALHOS FUTUROS 


No discorrer dos quatro capítulos deste trabalho acadêmico de conclusão de curso, procu- 
rou-se fazer uma abordagem técnica considerando que os sistemas embarcados podem ser defini- 
dos como sistemas de processamento digital que possuem seu software de controle — firmware — 
armazenado diretamente na memória do circuito eletrônico. Abordagem realizada a partir de uma 
concepção de aplicações dedicadas a uma tarefa específica, interagindo com o ambiente por meio 
de sensores e atuadores, estes para uso geral, empregados na maioria dos equipamentos eletrônicos 


atuais. 


5.1 CONTRIBUIÇÕES, CONSIDERAÇÕES E DESCOBERTAS 


Em detalhes, os três primeiros objetivos específicos do trabalho foram alcançados através 
da descrição de elementos de hardware, incluindo microprocessadores e barramentos de comuni- 
cação, e da explicação em software sobre os sistemas Linux e as interfaces de usuário executadas 
neste, além de concepções sobre diversos softwares livres como: Ubuntu, Debian, GTK+ e vxWid- 
gets. Com tal estruturação de tutorial, que faz parte do objetivo geral do trabalho, supriu-se a falta, 
tanto em artigos acadêmicos quanto em livros científicos, de bibliografias para especificamente 
tratar de interfaces gráficas em PC para uso em sistemas eletrônicos com microcontroladores. Atra- 
vés do desenvolvimento apresentado no capítulo IV, sobretudo por meio dos exemplos completos 
— com leituras e escritas — e finais, contemplam-se os três últimos objetivos específicos, visto que 
se abordou a temática da interface gráfica em Linux para sistemas AVR via USB usando GTK+ 
wxWidgets, além de operações concorrentes e em tempo real. Por isso, foram ampliadas as possi- 
bilidades com outros sistemas operativos que não Windows para projetos similares em particular, 
estas de caráter simples, portável e de baixo custo em termos de hardware e de software. A elabo- 
ração, propriamente dita, de casos de interfaces gráficas com interação de hardware que fossem 
próximos da realidade proporciona a resposta da primeira interrogante do trabalho. 

A proposta do trabalho, voltada para o desenvolvimento de interfaces gráficas para sistema 


embarcados, foi contemplada a partir da pesquisa bibliográfica, do estudo e da utilização de códigos 
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de linguagens computacionais C e C++, além de softwares específicos utilizados nos ambientes 
operacionais Windows e Linux. Ainda, há demonstrações e exemplos adotados na construção de 
interfaces gráficas de propósito geral, que foram aqui considerados essenciais para a compreensão, 
realização e efetivação dos objetivos iniciais estabelecidos para a elaboração deste trabalho. Dessa 
forma, os elementos essenciais — abordagem dos conceitos básicos e fundamentais para a utilização 
e o desenvolvimento de aplicações, a descrição do hardware e software necessários e os aspectos 
a serem observados para elaborar um projeto simplificado de interface de aplicação — estabelecidos 
como objetivos específicos foram aspectos contemplados e relevantes no tocante à utilização de 
componentes físicos e virtuais para a interface. Isso com a finalidade da interação com equipamen- 
tos elétricos e eletrônicos, amplamente utilizados no mundo do desenvolvimento tecnológico de 


todas as áreas do conhecimento e atividade humana. 


O trabalho incentiva a utilização de softwares livres para a interface homem-máquina: 
Ubuntu Linux 14.04, GCC 4.81, GTK+ 2.0/3.0, Code: :Blocks 16.02, wx Widgets 3.0, Atmel Studio 
6.2. Pelo caráter livre e aberto, tem-se a garantia de liberdade no controle do software — sistema, 
drivers, aplicativos — e segurança de acesso, além de orientação a usuários, disponibilidade a mí- 
nimo custo, entre outras qualidades; isso dado que são os custos de sistemas proprietários utilizados 
no desenvolvimento de aplicações computacionais em geral que representam o fator de maior bar- 
reira para a difusão do conhecimento e sua aplicação como instrumento de desenvolvimento indus- 
trial, sobretudo nos países cujo centro gravitacional do domínio tecnológico encontra-se situado e 
sob controle dos países desenvolvidos. 

No decorrer deste estudo, verificou-se que os sistemas embarcados em geral estão relacio- 
nados, necessariamente, ao uso de hardware — eletrônica — e software — aplicações em códigos — 
incorporados em um dispositivo com um objetivo pré-definido, visando a solução e a automação 
de processos específicos, de uso também específico ou geral. É nesse aspecto da objetividade que 
está a diferença entre uma aplicação embarcada e um computador de propósito geral, pois este 
último geralmente é dimensionado para atuação em um domínio de funções muito amplas, en- 
quanto os sistemas embarcados tem recursos dimensionados para uso singular. Em razão disso, 
como já foi tratado neste trabalho, o desenvolvimento de um aplicativo constituído de uma interface 
gráfica de usuário é, em geral, uma tarefa abstrata e complexa e suas características devem ser 
previstas pelo projetista considerando a disponibilidade das ferramentas tecnológicas, além de seu 


alcance e domínio. Por outro lado, como foi demonstrado no decorrer do capítulo II, conhecer, 
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dimensionar e dominar o hardware, objeto e destinatário da aplicação desenvolvida, não é menos 
importante do que domínio dos códigos construtores do software que há de se criar. Assim, é es- 
sencial o dimensionamento racional do hardware e do software. 

Por fim, no presente trabalho não se buscou esgotar a temática acerca da construção e apli- 
cação de sistemas embarcados, tendo a interface gráfica como elemento chave para a interação 
homem-máquina, ao contrário: diante da essencial predominância dos recursos computacionais no 
estudo da engenharia elétrica e suas aplicações, o objetivo geral e a resposta à última interrogante 
deste trabalho foram abrangidos pela contribuição introdutória da temática para o estudo, pesquisa 
e desenvolvimento profissional do futuro engenheiro eletricista. Nesse sentido, os desafios da in- 
tegração e implementação dos recursos tecnológicos computacionais disponíveis no mundo atual, 
que são aplicados subsidiariamente no estudo dos fenômenos elétricos e seus controles, tornam-se 
imperativos e devem ser uma preocupação do conjunto de todos aqueles responsáveis pela quali- 
dade do ensino, pesquisa e desenvolvimento do estudo da engenharia elétrica, eletrônica, mecânica, 
mecatrônica e áreas afins. 

Nas experiências computacionais realizadas, pode ser considerado que as medições e atua- 
ções foram em tempo real, pelo fato de estas, conforme a percepção do ser humano, se darem rápido 
o suficiente nos períodos considerados para os temporizadores. Porém, se ocorresse de tais elemen- 
tos de controle trabalharem com plantas de alta precisão, como de um osciloscópio, possivelmente 
a interface em GTK+ wx Widgets não conseguiria acompanhar o processo em tempo real. Isso está 
relacionado com as velocidades de processamento dos sistemas microprocessados, com as larguras 
de faixa dos barramentos e com os tempos de resposta dos softwares. 

Se o sistema for desenvolvido para interagir com outras plataformas e sistemas que preci- 
sem de informação amostrada com frequências específicas, precisa-se considerar o tempo máximo 
permitido de reação de interface para um trabalho conjunto em tempo real, isto é, entre computador 
e sistema embarcado. 

No tocante às diferentes distribuições do sistema Linux — Ubuntu 14.04, Debian 8 etc. — e 
aos pacotes aplicados — Code::Blocks 16.02, wxWidgets 3.0 — nestas, vale ressaltar a necessidade 
de o estudante ou profissional ter conhecimentos mínimos nas plataformas Linux. Isso envolve, em 
princípio, formas de instalação dos softwares, passos em linhas de comando, configurações de usu- 


ários, entre outros. 
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Observa-se, por fim, que o campo da programação de computadores é essencial no contexto 
dos tipos de sistemas microprocessados trabalhados, devido aos potenciais de cada linguagem em 
diferentes hardwares. Para sistemas embarcados e interfaces gráficas eficientes para estes, as lin- 
guagens de programação devem ter acesso a instruções de máquina, drivers de periféricos e, so- 
bretudo, otimizações em memória e velocidade. Somente assim uma interface em software pode 
vir a ser representativa, em tempo real, de um conjunto de dados e operações manipulados em 


firmware. 


5.2 PERSPECTIVAS DE TRABALHOS FUTUROS 


Como possibilidades e sugestões para trabalhos futuros, pode-se elaborar diferentes situa- 
ções em que uma interface gráfica em PC, especialmente se em ambiente Linux, fosse empregada 
para controlar determinado sistema eletrônico. Ao alcançar um comportamento ótimo em tempo 
real, percebe-se a oportunidade de criação de softwares similares ao LabVIEW da empresa National 
Instruments: um osciloscópio em software para circuitos elétricos conectados via hardware. A 
acessibilidade e gratuidade de tal abordagem através do Linux e de outras ferramentas trariam di- 
versas vantagens em projetos elétricos, sobretudo na área de processamento de sinais. 

Painéis e supervisórios estão entre as aplicações práticas padrões da interface gráfica em 
Linux PC para sistemas embarcados, uma vez que o GTK+ wx Widgets provê classes de componen- 
tes de ampla variedade: etiquetas, botões, barras de carregamento, imagens, animações etc. Por 
exemplo, um supervisório em software para uma subestação elétrica seria um projeto complexo, 
porém viável através dos conceitos e procedimentos tratados neste trabalho. 

Surgem muitas possibilidades de comunicação entre PCs e sistemas embarcados, como por 
módulos eletrônicos USB-RF para transmissão e recepção sem fio. Com a tendência da moderni- 
dade quanto à migração para sistemas de Internet, vem ainda a opção da interligação de interfaces 
gráficas através da rede. Uma interface gráfica de usuário poderia ser escrita com linguagens de 


integração Web — C%, Java — a fim de controlar sistemas eletrônicos distantes entre si. 
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Quanto ao material didático estruturado, posteriores pesquisas poderiam compreender as- 
pectos como interfaces gráficas em Windows para aplicações embarcadas, não em Linux. Outros- 
sim, códigos prontos e completos poderiam ser disponibilizados em sites na Internet para adaptação 
e realização de testes, sem contar com publicações em artigos, livros, revistas, entre outros. 

Finalmente, as criações, projetos e materiais aptos de serem apoiados são de extensão inde- 
finida. Cabe aos desenvolvedores de novas tecnologias aplicar, parcial ou totalmente, as ferramen- 


tas introduzidas e explicada no decorrer do trabalho de conclusão de curso. 
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Veículo Terrestre não Tripulado para o Monitoramento da Vida 
Selvagem 


Santos S. Jadson, Arancibia R. Josilene, Oliveira S. Yuri, Trindade J. Rodrigo e Alvarez 
A. Beatriz 


Abstract— This paper presents the development of an 
explorer vehicle to be applied in the monitoring of wild 
animals, patrolling of trails and collecting of data of'the inner 
forest environment. A remote controlled unmanned ground 
vehicle (UGV) was built, with the capability of sending 
real-time image to the operator, as well as information about 
temperature, humidity and environment luminosity, it was 
also combined with an ultrasonic sensor, which indicates the 
distance between the vehicle and the nearest frontal obstacle. 
The program code was developed in Arduino language, 
which is based in C++ and compiled with Arduino IDE 1.6.4. 
The developed project has proven to be efficient and useful in 
data collecting, communication with the operator and image 
capturing, but the vehicle's moving capability has shown to be 
limited when moving thru rough terrain, which indicates that 
the mobility system may need to be adapted to the land to be 
inspected. Tests conducted inside of the UFAC's campus 
confirmed the ARCODE efficiency in monitoring animals and 
data collecting. 

Keywords: Explorer Robot Car, Arduino, monitoring 
wildlife. 


Resumo— Este artigo apresenta o desenvolvimento de um 
veiculo explorador para ser aplicado no monitoramento de 
animais silvestres, no patrulhamento de trilhas e coleta de 
dados do ambiente interno da floresta. Foi construído um 
veículo terrestre não tripulado controlado remotamente, com 
capacidade de envio de imagens em tempo real para o 
operador, bem como para o envio de características de 
temperatura, umidade e luminosidade ambiente, também foi 
acoplado um sensor de distância que indica ao operador a 
distância que o carro se encontra dos maiores obstáculos. A 
programação foi desenvolvida em uma linguagem própria do 
Arduino baseada em C++, e compilada com Arduino IDE 
1.6.4. O projeto desenvolvido se mostrou eficiente e 
promissório na coleta de dados, na comunicação com o 
operador e na captura de imagens, entretanto para percorrer 
terrenos acidentados, poderá se fazer necessária a adaptação 
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do sistema de locomoção adequado ao terreno a ser 
inspecionado. Os testes realizados no campus da UFAC 
demostrou a eficiência do ARCODE no monitoramento de 
animais e coleta de dados ambientes, temperatura, umidade e 
luminosidade. 

Palavras Chaves: Carro robô explorador, 
monitoramento da vida selvagem. 


Arduino, 


I. INTRODUÇÃO 


monitoramento de animais silvestres em seu habitat 

natural é uma tarefa difícil de ser realizada, muitas vezes 

é necessário se passar dias até semanas dentro da mata 
fechada, ou colocar câmeras que com a aproximação de algum 
animal são ativadas, além de colocar em risco a vida dos 
observadores esses métodos na maioria das vezes, obriga que 
o profissional da biologia fique estagnado em uma “tocaia” a 
espreita dos animais. 

Os proprietários de terras também se interessaram por 
monitoramento da fauna em suas propriedades por uma 
variedade de razões, algumas das quais são a observação de 
vida selvagem e a identificação dos animais problemáticos. 
Além disso, os proprietários também podem querer avaliar a 
eficácia dos planos de gestão do habitat, monitorando 
respostas diferentes das espécies da vida selvagem. Alguns 
animais, como aves cantoras, são facilmente vistos e ouvidos, 
mas muitos animais ficam ocultos ou são noturnos, 
tornando-os difíceis de detectar, característica que é 
denominada hard-to-view. Para determinar a presença de 
estes animais, os proprietários devem usar frequentemente 
métodos indiretos, tais como faixas de identificação, fezes, ou 
tocas. 

Como uma alternativa tecnológica para ser utilizada no 
auxílio na identificação e monitoramento de espécies 
selvagens hard-to-view foi desenvolvido um veiculo terrestre 
não tripulado chamado ARCODE (Automóvel Remotamente 
Controlado para Obtenção de Dados de Exploração) que 
possui uma sonda para a coleta de dados como: captura de 
imagens, distância de objetos, quantidade de iluminação, 
temperatura e umidade ambiente. O ARCODE tem a 
vantagem de ser controlado remotamente pelo operador, 
assim o monitoramento pode ser realizado a uma distância 
segura dos animais selvagens e caso seja necessária o 
deslocamento para outro local, o operador não precisará 
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entrar na mata para realizar a operação. 

No desenvolvimento do veículo ARCODE foi utilizado a 
plataforma de desenvolvimento Arduino Uno como sendo um 
primeiro protótipo, e Arduino Nano na versão ARCODE 2.0. 
A plataforma de prototipagem Arduino é uma Open-Source 
(fonte aberta) constituída por um micro controlador ATMEL, 
juntamente com um hardware de fácil manipulação e uma 
plataforma de programação simples. A linguagem de 
programação utilizada é derivada da linguagem C++, devido a 
essas características e a vasta informação de exemplos da sua 
utilização, a plataforma Arduino foi utilizada no 
desenvolvimento do ARCODE. 

Neste artigo se descreve a utilização do ARCODE no 
monitoramento de animais selvagens dentro da Universidade 
Federal do Acre — UFAC, Campus Rio Branco. A onde ele 
capturou imagens de animais, ajudando no mapeamento de 
populações silvestres, bem como auxiliando o monitoramento 
do comportamento desses animais, quantidade de iluminação 
que costumam sair, umidade ambiente e temperatura ambiente 
que procuram nas florestas. 


II. TRABALHO PROPOSTO 


Foi almejado construir um veículo dotado da capacidade de 
coletar informações de ambientes hostis, e transmitir essas 
informações para o operador. Dessa forma, o veículo foi 
desenvolvido para que seja controlado remotamente por um 
operador, via comunicação Bluetooth ou por rádio frequência. 
Para a visualização do local de exploração é acoplado uma 
câmera no chassi do veículo, que envia imagens em tempo real 
dos lugares que estão sendo explorados. Além da câmera, 
foram acoplados sensores de luminosidade, temperatura, 
umidade, monóxido de carbono e obstáculos. O sensor de 
obstáculos foi estrategicamente colocado na parte frontal do 
ARCODE a fim de monitorar qualquer obstáculo, informando 
a distância que o carro se encontra da barreira. 

Para a construção do veículo foi utilizado um chassi de 
tanque-esteira Tamiya, mostrado na figura 1, que é composto 
por dois motores DC, duas esteiras e uma estrutura de 
prototipagem. Estrutura na qual foram montados todos os 
outros componentes. 


Figura 1 — Chassi Tamiya [Fonte: Tamiya]. 


Comando 
disponível? 


Sim 
Não 
Não 
Não 
Não 


Comando = 
Sensores? 


Não 


Figura 2 — Diagrama de fluxo do ARCODE. 


Mover para 
frente 
Mover para 
trás 
Mover à 
esquerda 


Leitura e envio de 
dados dos sensores 
ao usuário 


A programação foi desenvolvida na linguagem própria 
Arduino. O diagrama que descreve a lógica de operação do 
sistema é mostrado na figura 2. 

O desenvolvimento do protótipo foi dividido em quatro 
etapas: leitura dos sensores, controle dos motores, 
desenvolvimento e construção do chassi e acoplamento da 
câmera ao veículo. 


HI. MATERIAIS E MÉTODOS 


A construção do ARCODE 2.0 passou por várias fazes de 
desenvolvimento e adaptações. O primeiro protótipo 
construído foi um carro RC controlado com Arduino, 
protótipo mostrado na figura 3, posteriormente foram 
realizadas upgrades (melhorias) gerando o ARCODE 1.0, 
mostrado na figura 4, e o ARCODE 2.0 que é a versão 
utilizada nesta aplicação e é mostrada na figura 5. 
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A. Carro RC Controlado com Arduino 


O primeiro protótipo constituía de um Chassi Tamiya, dois 
Arduino Uno, quatro botoeiras push-boton, três baterias 9V, 
um comunicador RF 433MHZ, duas protoboard, dois 
motores DC, um CI L293, uma caixa de redução para os 
motores e jumpers (fios de conexão). Neste primeiro protótipo 
um Arduino foi utilizado como receptor e outro como 
transmissor, as botoeiras funcionavam como entrada de dados 
para o sistema e os motores como a saída, ao pressionar uma 
botoeira o nível lógico de uma das entradas do 
arduino-transmissor era acondicionado para o nível lógico 
baixo, o arduino-transmissor constantemente estava fazendo a 
leitura dos níveis lógicos dos pinos de entrada, ao detectar 
uma variação nesses valores ele enviava um sinal para o 
arduino-receptor, através do módulo de comunicação RF 
433MHZ. O arduino-receptor ao reconhecer o sinal enviado o 
interpretava e de acordo com a ordem recebida, suas saídas 
eram elevadas para o nível lógico alto, as saídas do 
arduino-receptor estavam ligadas ao CI L293 que por sua vez 
acionava os motores. 


Figura 3 - CARRO RC COM ARDUINO [Fonte Autor] 


B. ARCODE 1.0 


No segundo protótipo foram realizados vários upgrads. Na 
comunicação foi utilizado o módulo RF APC220, foram 
incrementados sensores de temperatura LM35, luminosidade 
LDR, distância HC-SRO04, gás MQ-7, sensor de umidade e 
temperatura HDT11 e um buzzer, na figura 5 pode ser visto o 
esquema de ligação destes componentes. Com a utilização do 
Módulo RF APC220, o ARCODE ganhou mais mobilidade, 
sendo controlado pelo notebook e com um alcance de superior 
a 100 metros sem obstáculos, sendo o módulo RF 433MHZ 
não chegava a 5 metros. Para as conexões ainda foram 
utilizadas uma protoboard e jumpers. Os dados coletados 
pelos sensores eram exibidos no serial monitor do editor de 
programação arduino, os comandos também eram enviados 
para o ARCODE através do serial monitor do arduino. 
Detalhes do desenvolvimento e comportamento desta versão 
do protótipo podem ser encontrados na referência [1]. 


Figura 4 —- ARCODE 1.0 [Fonte Autor] 


Figura 5 — Esquema de ligação dos componentes, este esquema foi projetado 
com o software Fritzing [Fonte Autor]. 


C. ARCODE 2.0 


O ARCODE 2.0 conta com um sistema de comunicação via 
Bluetooth, utilizando o módulo HC-05, que faz a 
comunicação do Arduino com o celular ou notebook, o 
alcance do módulo de comunicação HC-05 limita-se a 20 
metros, sem obstáculos, entretanto, devido à mobilidade que o 
controle via celular proporciona o controle via Bluetooth se 
tornou mais vantajoso. O Arduino Uno utilizado como 
controlador nos outros protótipos foi substituído pelo Arduino 
Nano, que tem uma menor quantidade de pinos de entrada e 
saída de dados, e ocupa uma menor área, esta substituição foi 
realizada visando o encaixe dos componentes no chassi, e a 
diminuição do peso de todo o sistema. Para evitar maus 
contatos e falhas ocasionadas pela oxidação, os jumpers de 
conexões foram substituídos por uma placa de circuito 
impresso desenvolvida no software Proteus (Figura 6a e 6b). 
Nesta versão do protótipo e para a aplicação descrita neste 
artigo, o sensor de gás e o buzzer foram removidos do sistema 
devido ao alto consumo da bateria e um celular foi acoplado 
no chassi para a captura de imagens. O software EPOCCAM 
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está sendo utilizada para a captura de imagens, onde a partir 
da conexão com uma rede local as imagens capturadas pela 
câmera do celular são enviadas para um notebook que esteja 
conectado a mesma rede. Assim, para o monitoramento com 
imagens deve-se ter instalado o aplicativo EPOCCAM no 
celular e no notebook, criar uma rede com o notebook, 
ingressar o celular na rede criada, e rodar o aplicativo no 
celular e no notebook. O chassi foi projetado utilizando o 
software Autocad e confeccionado em acrílico como pode ser 
visto na figura 7. 

Para o controle via notebook foi desenvolvida uma 
interface gráfica visando uma eficiente comunicação 
homem-máquina (Figura 8). Tal interface foi desenvolvida 
utilizando a ferramenta de desenvolvimento IDE C++ 
Builder, esta reflete tanto as características de acionamento 
quanto as de sensoriamento do robô, sendo então uma forma 
simplificada e interativa de representar o comportamento 
físico do controle do ARCODE. 

Internamente, a interface comunica-se com os 
microprocessadores Arduino instalados no veículo. Isso é 
feito de modo oculto através do simples auxiliar Termite 3.1 
da empresa IPB CompuPhase, um software com 
características de driver capaz de comunicar-se no padrão da 
plataforma Arduino através de portas USB de um 
computador. Assim, no nível de programação a interface 
gráfica do ARCODE pode ser entendida como uma extensão 
gráfica do Termite 3.1, o que ocorre ao ponto de a instalação 
do Termite 3.1 ser um pré-requisito para o funcionamento 
correto do painel. 

O manejo em si do painel de controle funciona da seguinte 
forma: primeiramente, escolhe-se a porta e a taxa de 
transmissão de dados com as quais a interface deve se 
conectar ao carro robô; após selecionar também o tipo de 
terreno pelo qual o automóvel deve percorrer, clica-se no 
botão Conectar, o que inicia a comunicação com os 
acionadores e sensores físicos do robô; finalmente, 
controlam-se os motores do carro pelo teclado do computador 
e são verificadas as informações captadas pelos sensores por 
meio das barras de progresso e botões. 


(b) 


Figura 6 — (a) Projeto da placa em Proteus. (b) Placa pronta de Circuito 
Impresso [Fonte Autor] 
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Figura 7 — a) Projeto do chassi AutoCad. b) Chassi físico montado [Fonte 
Autor] 
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Figura 8 — Interface gráfica. [Fonte Autor] 


IV. RESULTADOS E DISCUSSÃO 


O monitoramento realizado com o ARCODE no campus 
capturou algumas imagens, caracterizando parte da 
biodiversidade da fauna da floresta do campus sob algumas 
condições ambientais específicas. 

Estes testes iniciais realizados têm por objetivo mostrar as 
características do ARCODE e a possibilidade dele estar 
preparado para realizar estudos mais aprofundados 
considerando alguma espécie em particular ou alguma área 
específica do Campus. 

Na figura 9 pode se ver uma das imagens captadas nos 
testes realizados nas proximidades do lago da UFAC, os testes 
constataram a presença de famílias de capivaras 
(Hydrochoerus hydrochaeris) vivendo nas áreas reservadas 
do Campus. Sendo que elas saem para o pasto quando a 
luminosidade chega próximo de 40%, a umidade ambiente 
corresponde a 80% e a temperatura cai para 22 ºC. Uma 
característica que foi observada é que a saída das capivaras da 
floresta densa para começarem a pastar as gramíneas está 
relacionada diretamente com a temperatura do ambiente. 


Figura 9 — Capivara (Hydrochoerus hydrochaeris) caminhando nas 
proximidades do lago da UFAC [Fonte Autor]. 


Nas proximidades do parque zoobotânico, ainda dentro do 
Campus da UFAC, foi verificada a presença de vários gatos 
domésticos (Felis silvestris catus) vivendo na orla da floresta, 
no seguimento realizado pôde ser constatado, que apesar de 
serem animais de hábitos majoritariamente noturnos, eles 
saem em busca de alimentos como: pequenos roedores, 
pequenos macacos, lagartos, pássaros, etc. também durante o 
dia. 


E 


tre] » 8 DO 


FR 


(ra ra L a 
Ev e €(7 o/a] man AU use 


Figura 10 — Gato doméstico em busca de alimento (Felis silvestris catus) 
[Fonte Autor]. 


Após os testes operacionais realizados foi constatado que o 
ARCODE pode ser aplicado no estudo de animais silvestres, 
sendo possível não apenas o monitoramento, mas também as 
características do ambiente em que ele se encontra, 
proporcionando não apenas segurança ao observador, mas 
também dados das condições ambientais do seu habitat. 

Assim, o ARCODE se mostrou eficiente para o 
monitoramento de animais silvestres, podendo ser operado a 
distâncias seguras, podendo mudar de local de observação 
sem a necessidade da presença humana por perto. 


V. CONCLUSÃO 


Este projeto descreve o desenvolvimento de um veículo de 
exploração remotamente controlado que pode ser utilizado 
para o monitoramento de animais, auxílio no mapeamento de 
trilhas e coleta de dados do ambiente interno da floresta 
amazônica. 

Os testes realizados no campus da UFAC demostrou a 
eficiênciado ARCODE no monitoramento de animais e coleta 
de dados do ambiente como: temperatura, umidade e 
luminosidade. Para uma melhor utilização do ARCODE está 
prevista a utilização de uma câmera com visão noturna, pois 
com esta câmera o ARCODE estará preparado para 
acompanhar ou monitorar uma variedade de animais silvestres 
com hábitos noturnos. 

Para o aprimoramento do projeto está se pensando 
desenvolver algoritmos de tracking para dotar aa ARCODE 
da capacidade de seguir objetos em movimento. Também está 
se pensando substituir as esteiras do veículo por rodas, para 
evitar que o carro atole ou que as esteiras se soltem sob 
algumas características do terreno. 
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